php.net |  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
Votes:1
Avg. Score:5.0 ± 0.0
Reproduced:0 of 1 (0.0%)
From: a dot bodemer at brillux dot de Assigned: tony2001
Status: Closed Package: OCI8 related
PHP Version: 5.1.4 OS: Linux x86
Private report: No CVE-ID:
 [2006-07-20 14:16 UTC] a dot bodemer at brillux dot de
Description:
------------
Hallo,

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:
---------------
<?php
$query= "declare
  n_status NUMBER(2);
begin
  n_status := -1 ;
  IF :n_status = 0 THEN
    :retValue := :n_status;
  END IF;
end;";

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

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.

Patches

Add a Patch

Pull Requests

Add a Pull Request

History

AllCommentsChangesGit/SVN commitsRelated reports
 [2006-07-20 14:18 UTC] tony2001@php.net
Please try using this CVS snapshot:

  http://snaps.php.net/php5.2-latest.tar.gz
 
For Windows:
 
  http://snaps.php.net/win32/php5.2-win32-latest.zip


 [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] tony2001@php.net
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
http://bugs.php.net/bugs-generating-backtrace.php for *NIX and
http://bugs.php.net/bugs-generating-backtrace-win32.php 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); 
 begin
 :retValue := 0;  -- set default value
  n_status := 1 ;
  IF :n_status = 0 THEN
    :retValue := :n_status;
  END IF;
end;";
 [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] tony2001@php.net
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] tony2001@php.net
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
http://snaps.php.net/.
 
Thank you for the report, and for helping us make PHP better.


 
PHP Copyright © 2001-2014 The PHP Group
All rights reserved.
Last updated: Thu Apr 17 12:01:59 2014 UTC