php.net |  support |  documentation |  report a bug |  advanced search |  search howto |  statistics |  random bug |  login
Bug #22836 returning reference to uninitialized variable
Submitted: 2003-03-23 22:53 UTC Modified: 2003-07-30 11:53 UTC
Votes:3
Avg. Score:5.0 ± 0.0
Reproduced:3 of 3 (100.0%)
Same Version:2 (66.7%)
Same OS:2 (66.7%)
From: brunswim at seas dot upenn dot edu Assigned:
Status: Closed Package: Scripting Engine problem
PHP Version: 4.3.2-RC OS: Debian Linux 2.4.18
Private report: No CVE-ID:
 [2003-03-23 22:53 UTC] brunswim at seas dot upenn dot edu
f() returns a reference to an uninitialized variable $a. In subsequent calls, this appears to corrupt the local variable $x. The following script demonstrates the problem.

<?
function &f() {
	$x = "foo";
	var_dump($x);
	print "<br>\n$x<br>\n";
	return($a);
}
for ($i = 0; $i < 8; $i++) {
	$h =& f();
}
?>

On the third call to f(), $x prints fine but is reported to be NULL by var_dump().  Operations on $x will subsequently cause unexpected behavior.

We can change the behavior of $x by adding the line:
$y = "bar";
after the line:
$x = "foo";

If we do this, printing $x returns "bar" but var_dump() still returns NULL.

Patches

Add a Patch

Pull Requests

Add a Pull Request

History

AllCommentsChangesGit/SVN commitsRelated reports
 [2003-03-24 01:45 UTC] brunswim at seas dot upenn dot edu
For the record, the output I am getting for this script is:

string(3) "foo"
foo
string(3) "foo"
foo
NULL
foo
NULL
foo
NULL
foo
NULL
foo
NULL
foo
NULL
foo
 [2003-03-24 03:41 UTC] sniper@php.net
I get same output plus these leaks:

/usr/src/web/php/php4/Zend/zend_execute.c(436) :  Freeing 0x0875A804 (4 bytes), script=t.php
/usr/src/web/php/php4/Zend/zend_variables.c(111) : Actual location (location was relayed)
/usr/src/web/php/php4/Zend/zend_execute.c(1702) :  Freeing 0x0875A6EC (12 bytes), script=t.php


 [2003-03-24 04:29 UTC] moriyoshi@php.net
This problem has much to do with bug #22367.

Assumed reason: unexpected change of EG(uninitialized_zval_ptr)..

 [2003-03-24 11:39 UTC] brunswim at seas dot upenn dot edu
This seems similar to bug #22367 but causes problems more globally.  Obviously, this is reproducible with a short script.  In the following similar example, it may be more apparent that global corruption is taking place.

<?
function &f1() {
	return($a);
}
function f2() {
	$x = "bar";
	$y = "bug!";
	var_dump($x);
	print "<br>\n$x";
}

$i =& f1();
$j =& f1();
f2();
?>

The output that I get is:
NULL
bug!

So, after 2 references to uninitialized variables, everything behaves unpredictably.

It is easy to see how this situation could occur in "real" code.  In our case, we were building objects from a database select query.  We were iterating through the rows and putting data in $a[].  When there were no rows, $a was never initialized, but it was extremely difficult to isolate the problem because other functions, across many files, were misbehaving due to this bug.
 [2003-03-25 17:41 UTC] jseverson at myersinternet dot com
Same as bug <a href="http://bugs.php.net/bug.php?id=20583">Bug 20583</a>

I've posted a list of all bug reports I've found that seem to be related to this same php bug, 20583.
 [2003-07-29 12:57 UTC] iliaa@php.net
This bug has been fixed in CVS.

In case this was a PHP problem, 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/.
 
In case this was a documentation problem, the fix will show up soon at
http://www.php.net/manual/.

In case this was a PHP.net website problem, the change will show
up on the PHP.net site and on the mirror sites in short time.
 
Thank you for the report, and for helping us make PHP better.


 [2003-07-30 11:53 UTC] sniper@php.net
This will most likely be fixed in PHP 5 earliest.

 
PHP Copyright © 2001-2014 The PHP Group
All rights reserved.
Last updated: Sun Apr 20 19:01:51 2014 UTC