|  support |  documentation |  report a bug |  advanced search |  search howto |  statistics |  random bug |  login
Bug #38161 oci_bind_by_name return memory dump
Submitted: 2006-07-20 14:16 UTC Modified: 2006-08-09 12:20 UTC
Avg. Score:5.0 ± 0.0
Reproduced:0 of 1 (0.0%)
From: a dot bodemer at brillux dot de Assigned: tony2001 (profile)
Status: Closed Package: OCI8 related
PHP Version: 5.1.4 OS: Linux x86
Private report: No CVE-ID: None
 [2006-07-20 14:16 UTC] a dot bodemer at brillux dot de

we use a Linux/Apache/Oracle/PHP on a X86 system. 
We tested the Codesample on PHP 5.1.4 with Oracle 8.1/10.1 and Apache 2.0.46/2.0.58. Every times the same result, a memory dump from the current apache.

Reproduce code:
$query= "declare
  n_status NUMBER(2);
  n_status := -1 ;
  IF :n_status = 0 THEN
    :retValue := :n_status;

$conn = OCILogon("wws", "wws", "zente");
$stmt = OCIParse($conn, $query);
OCIBindByName($stmt, ":retValue", $returnValue,50);
OCIBindByName($stmt, ":n_status", $n_status,50);

print "\n<pre><br>OCIExecute() ret=$ret";
print "\n<br> Return Value=".$returnValue;

Expected result:
The return value must be NULL.

Actual result:
The result is a memory dump from the current apache.


Add a Patch

Pull Requests

Add a Pull Request


AllCommentsChangesGit/SVN commitsRelated reports
 [2006-07-20 14:18 UTC]
Please try using this CVS snapshot:
For Windows:

 [2006-07-20 15:05 UTC] a dot bodemer at brillux dot de
The SampleCode produce in php5.2-200607190630 the same result, a memory dump. 
In all Testcases the script run without a PHP Error message or a 'Segmentation Failure'.
 [2006-07-20 15:48 UTC]
Thank you for this bug report. To properly diagnose the problem, we
need a backtrace to see what is happening behind the scenes. To
find out how to generate a backtrace, please read for *NIX and for Win32

Once you have generated a backtrace, please submit it to this bug
report and change the status back to "Open". Thank you for helping
us make PHP better.

 [2006-07-21 03:36 UTC] cjbj at hotmail dot com
Tony you shouldn't need a stack dump for this.  Just try a  var_dump($returnValue) at the end of the script.  Because no value has been returned in the variable it is being treated as a 64K string and printing garbage.

The workaround for users is to make sure that the PL/SQL block always sets variable values in all possible code paths.  Something like:

$query= "declare   
 n_status NUMBER(2); 
 :retValue := 0;  -- set default value
  n_status := 1 ;
  IF :n_status = 0 THEN
    :retValue := :n_status;
 [2006-07-28 01:00 UTC] php-bugs at lists dot php dot net
No feedback was provided for this bug for over a week, so it is
being suspended automatically. If you are able to provide the
information that was originally requested, please do so and change
the status of the bug back to "Open".
 [2006-07-28 11:55 UTC] a dot bodemer at brillux dot de
Hello toni,
it is not the problem to implement a workaround. I meen it 
is important find the bug. May be there is more than this?
I doen't hope it.
 [2006-07-28 12:02 UTC]
Actually I have a workaround, but I'm still waiting for feedback from Oracle people - it looks like the problem is in Oracle itself, since Oracle should not call the callback if it's not going to set variable's value and if it finally called it - it should at least say there was no value.
Since there is no way to detect "called, but no value set" situation, the workaround is apparently pretty ugly.
 [2006-08-09 12:20 UTC]
This bug has been fixed in CVS.

Snapshots of the sources are packaged every three hours; this change
will be in the next snapshot. You can grab the snapshot at
Thank you for the report, and for helping us make PHP better.

PHP Copyright © 2001-2020 The PHP Group
All rights reserved.
Last updated: Mon Nov 23 19:01:26 2020 UTC