#31217 [NEW]: extract($GLOBALS, EXTR_REFS) corrupts memory
From: cdragon at draconic dot com
Operating system: win2k
PHP version: 5CVS-2004-12-18 (dev)
PHP Bug Type: Reproducible crash
Bug description: extract($GLOBALS, EXTR_REFS) corrupts memory
Description:
Since php 5.0.1, extract($GLOBALS, EXTR_REFS) seems to corrupt code memory
and cause various random problems. In my test case, it caused
COM(someobject) to always return null, and in another case it just
caused some strange output of a 1 instead of the expected strings. I
never had a problem in php 5.0.0 up to CVS snapshot
php5.0-win32-200407301630. Commenting out extract($GLOBALS, EXTR_REFS)
fixes all strange behavior.
I had a similar problem in php 4 which I reported as bug id 25708. That
bug was fixed and I never had a problem again until 5.0.1.
Reproduce code:
---
extract($GLOBALS, EXTR_REFS);
$query = new COM(IXSSO.Query);
if(is_object($query) == false) {
var_dump($query);
print Can't create IXSSO Query object.;
exit();
}
Expected result:
Nothing
Actual result:
--
PHP has encountered an Access Violation at 01D5F185
--
Edit bug report at http://bugs.php.net/?id=31217edit=1
--
Try a CVS snapshot (php4): http://bugs.php.net/fix.php?id=31217r=trysnapshot4
Try a CVS snapshot (php5.0):
http://bugs.php.net/fix.php?id=31217r=trysnapshot50
Try a CVS snapshot (php5.1):
http://bugs.php.net/fix.php?id=31217r=trysnapshot51
Fixed in CVS:http://bugs.php.net/fix.php?id=31217r=fixedcvs
Fixed in release:http://bugs.php.net/fix.php?id=31217r=alreadyfixed
Need backtrace: http://bugs.php.net/fix.php?id=31217r=needtrace
Need Reproduce Script: http://bugs.php.net/fix.php?id=31217r=needscript
Try newer version: http://bugs.php.net/fix.php?id=31217r=oldversion
Not developer issue: http://bugs.php.net/fix.php?id=31217r=support
Expected behavior: http://bugs.php.net/fix.php?id=31217r=notwrong
Not enough info:
http://bugs.php.net/fix.php?id=31217r=notenoughinfo
Submitted twice:
http://bugs.php.net/fix.php?id=31217r=submittedtwice
register_globals:http://bugs.php.net/fix.php?id=31217r=globals
PHP 3 support discontinued: http://bugs.php.net/fix.php?id=31217r=php3
Daylight Savings:http://bugs.php.net/fix.php?id=31217r=dst
IIS Stability: http://bugs.php.net/fix.php?id=31217r=isapi
Install GNU Sed: http://bugs.php.net/fix.php?id=31217r=gnused
Floating point limitations: http://bugs.php.net/fix.php?id=31217r=float
No Zend Extensions: http://bugs.php.net/fix.php?id=31217r=nozend
MySQL Configuration Error: http://bugs.php.net/fix.php?id=31217r=mysqlcfg
#26745 [NEW]: No input file specified. with doc_root set to a path prefix
From: cdragon at draconic dot com Operating system: windows 2000 PHP version: 5.0.0b2 (beta2) PHP Bug Type: IIS related Bug description: No input file specified. with doc_root set to a path prefix Description: I've been setting up a development server with the exact same configuration as a live server. Instead of using php 4.3.x I decided to try 5b3. I use the same php.ini file. I have IIS set to host two web sites in the following two directories: c:\inetpub\wwwroot\www.draconic.com c:\inetpub\wwwroot\www.draconic.net In php.ini, I have doc_root set to c:\inetpub\wwwroot so that files in either of these directories can be loaded. Yet when I load any php page from either site I get the error No input file specified. I am using IIS 5 under win2k using the ISAPI version of php 5b3. I found that by changing doc_root from c:\inetpub\wwwroot to c:\inetpub\wwwroot\www.draconic.com, I can get the php pages to work reliably for the first web site. However, this means I get the No input file specified error when I try to load pages from c:\inetpub\wwwroot\www.draconic.net. With doc_root set to c:\inetpub\wwwroot I get the No input file specified most of the time, but I found it would occasionally load the php page correctly (maybe that was a caching thing?), or even give me a memory access violation when I tried to use the include(...) statement! I can't figure out what was different when it worked or when it access violationed, but something seems to be seriously broken with doc_root in php 5b3. -- Edit bug report at http://bugs.php.net/?id=26745edit=1 -- Try a CVS snapshot (php4): http://bugs.php.net/fix.php?id=26745r=trysnapshot4 Try a CVS snapshot (php5): http://bugs.php.net/fix.php?id=26745r=trysnapshot5 Fixed in CVS: http://bugs.php.net/fix.php?id=26745r=fixedcvs Fixed in release: http://bugs.php.net/fix.php?id=26745r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=26745r=needtrace Need Reproduce Script: http://bugs.php.net/fix.php?id=26745r=needscript Try newer version: http://bugs.php.net/fix.php?id=26745r=oldversion Not developer issue:http://bugs.php.net/fix.php?id=26745r=support Expected behavior: http://bugs.php.net/fix.php?id=26745r=notwrong Not enough info:http://bugs.php.net/fix.php?id=26745r=notenoughinfo Submitted twice:http://bugs.php.net/fix.php?id=26745r=submittedtwice register_globals: http://bugs.php.net/fix.php?id=26745r=globals PHP 3 support discontinued: http://bugs.php.net/fix.php?id=26745r=php3 Daylight Savings: http://bugs.php.net/fix.php?id=26745r=dst IIS Stability: http://bugs.php.net/fix.php?id=26745r=isapi Install GNU Sed:http://bugs.php.net/fix.php?id=26745r=gnused Floating point limitations: http://bugs.php.net/fix.php?id=26745r=float
#25708 [WFx]: extract($GLOBALS, EXTR_REFS); can corrupt the $GLOBALS array.
ID: 25708
User updated by: cdragon at draconic dot com
Reported By: cdragon at draconic dot com
Status: Wont fix
Bug Type: Variables related
Operating System: Windows 2000 Server
PHP Version: 4CVS-2003-09-30 (stable)
New Comment:
Well, thank you for your quick (but rude) response.
It is certainly not useless (or stupid) to extract references to
globals. Extracting them without using the REFS flag creates deep
copies of every variable (if I understand things correctly), which is
very wasteful of resources. More importantly, you can't modify the
contents of a global string unless you extract with REFS or use an
alternate method. For example:
$var = x;
extrTest();
print var=$varp;
function extrTest() {
extract($GLOBALS);
//global $var;
//extract($GLOBALS, EXTR_REFS);
//$GLOBALS[var] = y;
$var = y;
}
Will print var=x instead of the desired var=y (which you can get
using any of the commented-out lines). Since there are obviously other
syntactic alternatives, I don't _have_ to use the REFS method.
However, I would certainly consider it a serious bug that you can cause
PHP to access violation and exhibit randomish, hard to diagnose errors
by doing something that actually _works most of the time_, serves a
valid purpose, seems like it should work (without knowing some things
about PHP's inner workings), and is not even cautioned against anywhere
in the documentation that I can find.
Previous Comments:
[2003-09-30 20:57:15] [EMAIL PROTECTED]
In short: Don't do this.
Longer version: GLOBALS is special variable, using extract() on it is
a) pointless, b) stupid, c) useless.
GLOBALS references itself in it, when you try to extract it's contents
as references, you'll end up with circular references which of course
will cause a crash.
[2003-09-30 18:23:05] cdragon at draconic dot com
Description:
Using extract($GLOBALS, EXTR_REFS); can cause the left hand side of two
globals set by-value equal to one-another to become corrupted in the
$GLOBALS array. Hard to explain in English, but easier to see in the
code below.
Reproduce code:
---
$sortColumn = Affinity;
// Using $lastSortColumn = substr($sortColumn, 0); fixes the bug
$lastSortColumn = $sortColumn;
print sort= . $GLOBALS['sortColumn'] . lastsort= .
$GLOBALS['lastSortColumn'] . p;
extractGlobs();
print sort= . $GLOBALS['sortColumn'] . lastsort= .
$GLOBALS['lastSortColumn'] . p;
function extractGlobs()
{
// Commenting out the line below fixes the bug. So does not using
the EXTR_REFS flag.
extract($GLOBALS, EXTR_REFS);
}
Expected result:
sort=Affinity lastsort=Affinity
sort=Affinity lastsort=Affinity
Actual result:
--
sort=Affinity lastsort=Affinity
sort=Affinity lastsort=
or, randomly, you get an access violation instead:
PHP has encountered an Access Violation at 02CFF32F
(the 02CFF32F is variable)
--
Edit this bug report at http://bugs.php.net/?id=25708edit=1
