#20487 [NEW]: mod_php crashes under Apache 1.3.27 & MaxRequestsPerChild=infinite
From: [EMAIL PROTECTED] Operating system: Windows 2000 PHP version: 4.3.0RC1 PHP Bug Type: Reproducible crash Bug description: mod_php crashes under Apache 1.3.27 & MaxRequestsPerChild=infinite When I use MaxRequestsPerChild 0 (e.g. infinite) in httpd.conf, sometimes Apache crashes. I have tested this bug on framed page (it is phpMyAdmin, two frames in frameset). When I use only one page (without frames), I have to press Reload button (F5 in Internet Explorer) many times (I rather hold it) to produce crash. I think something's wrong in multithreaded code in php4apache.dll: it crashes when two requests occurs at the SAME TIME (often, but not always). Tere is no bug in 4.2.3, but I cannot use php4apache.dll from 4.2.3 for 4.3.0 - it crashes immediately. -- Edit bug report at http://bugs.php.net/?id=20487&edit=1 -- Try a CVS snapshot: http://bugs.php.net/fix.php?id=20487&r=trysnapshot Fixed in CVS: http://bugs.php.net/fix.php?id=20487&r=fixedcvs Fixed in release: http://bugs.php.net/fix.php?id=20487&r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=20487&r=needtrace Try newer version: http://bugs.php.net/fix.php?id=20487&r=oldversion Not developer issue:http://bugs.php.net/fix.php?id=20487&r=support Expected behavior: http://bugs.php.net/fix.php?id=20487&r=notwrong Not enough info:http://bugs.php.net/fix.php?id=20487&r=notenoughinfo Submitted twice:http://bugs.php.net/fix.php?id=20487&r=submittedtwice register_globals: http://bugs.php.net/fix.php?id=20487&r=globals PHP 3 support discontinued: http://bugs.php.net/fix.php?id=20487&r=php3 Daylight Savings: http://bugs.php.net/fix.php?id=20487&r=dst IIS Stability: http://bugs.php.net/fix.php?id=20487&r=isapi
#20487 [Fbk->Opn]: mod_php crashes under Apache 1.3.27 & MaxRequestsPerChild=infinite
ID: 20487 User updated by: [EMAIL PROTECTED] Reported By: [EMAIL PROTECTED] -Status: Feedback +Status: Open Bug Type: Reproducible crash Operating System: Windows 2000 PHP Version: 4.3.0RC1 New Comment: Just get Apache 1.2.27, install PHP as Apache module, open http://localhost and press Reload button 20 times quickly (you may also hold Ctrl+R, it crashes too). You will see GP Fault message. No extensions are loaded in php.ini, no Apache module used instead of mod_php. How can I say more? Previous Comments: [2002-11-19 20:00:55] [EMAIL PROTECTED] Not enough information was provided for us to be able to handle this bug. Please re-read the instructions at http://bugs.php.net/how-to-report.php If you can provide more information, feel free to add it to this bug and change the status back to "Open". Thank you for your interest in PHP. [2002-11-18 14:54:33] [EMAIL PROTECTED] When I use MaxRequestsPerChild 0 (e.g. infinite) in httpd.conf, sometimes Apache crashes. I have tested this bug on framed page (it is phpMyAdmin, two frames in frameset). When I use only one page (without frames), I have to press Reload button (F5 in Internet Explorer) many times (I rather hold it) to produce crash. I think something's wrong in multithreaded code in php4apache.dll: it crashes when two requests occurs at the SAME TIME (often, but not always). Tere is no bug in 4.2.3, but I cannot use php4apache.dll from 4.2.3 for 4.3.0 - it crashes immediately. -- Edit this bug report at http://bugs.php.net/?id=20487&edit=1
#20487 [Com]: mod_php crashes under Apache 1.3.27 & MaxRequestsPerChild=infinite
ID: 20487 Comment by: [EMAIL PROTECTED] Reported By: [EMAIL PROTECTED] Status: Open Bug Type: Reproducible crash Operating System: Windows 2000 PHP Version: 4.3.0RC1 New Comment: Sorry, maybe this bug is hard-reproducible in other machines. Well, then you may use the following script: /index.html: /test.php: -- Apache 1.3.27, Windows 2000 SP2, 4.3.0RC1. Load http://localhost/index.html, then press Reload button. You will see GP Fault message immediately. See that you need at least TWO frames in frameset to emulate simultaneous requests. NEXT (!) Reload will kick ass. Previous Comments: [2002-11-20 07:39:28] [EMAIL PROTECTED] Just get Apache 1.2.27, install PHP as Apache module, open http://localhost and press Reload button 20 times quickly (you may also hold Ctrl+R, it crashes too). You will see GP Fault message. No extensions are loaded in php.ini, no Apache module used instead of mod_php. How can I say more? [2002-11-19 20:00:55] [EMAIL PROTECTED] Not enough information was provided for us to be able to handle this bug. Please re-read the instructions at http://bugs.php.net/how-to-report.php If you can provide more information, feel free to add it to this bug and change the status back to "Open". Thank you for your interest in PHP. [2002-11-18 14:54:33] [EMAIL PROTECTED] When I use MaxRequestsPerChild 0 (e.g. infinite) in httpd.conf, sometimes Apache crashes. I have tested this bug on framed page (it is phpMyAdmin, two frames in frameset). When I use only one page (without frames), I have to press Reload button (F5 in Internet Explorer) many times (I rather hold it) to produce crash. I think something's wrong in multithreaded code in php4apache.dll: it crashes when two requests occurs at the SAME TIME (often, but not always). Tere is no bug in 4.2.3, but I cannot use php4apache.dll from 4.2.3 for 4.3.0 - it crashes immediately. -- Edit this bug report at http://bugs.php.net/?id=20487&edit=1
#19689 [Com]: 4.2.3 and higher "include" operator mistake
ID: 19689
Comment by: [EMAIL PROTECTED]
Reported By: [EMAIL PROTECTED]
Status: Closed
Bug Type: Scripting Engine problem
Operating System: Windows
PHP Version: 4CVS-2002-10-01
New Comment:
I'd like to say that in php-4.3.0RC1-Win32 there are problems with
fopen:
bug.php:
\n";
fopen("/a.txt","w");
?>
Z:\!distrib\php\php-4.3.0RC1-Win32>php.exe bug.php
Z:\!distrib\php\php-4.3.0RC1-Win32
Warning: fopen(/a.txt) [http://www.php.net/function.fopen]: failed to
create stream: No such file or directory in
Z:\!distrib\php\php-4.3.0RC1-Win32\bug.php on line 3
You see if I use z:/a.txt, all works correctly.
In PHP 4.3.0-dev (cli) (built: Nov 23 2002 18:15:57) everything seems
to be OK.
Previous Comments:
[2002-11-14 07:46:05] [EMAIL PROTECTED]
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.
[2002-10-29 07:28:00] [EMAIL PROTECTED]
Hi all,
php.ini let you do a quick and easy hack to solve this bug for Win2000
(maybe other WinOS will work with this too):
Only change include_path in php.ini as follows:
include_path = "c:"
looks strange but solves the problem ...
Have fun : deka
[2002-10-13 21:41:00] [EMAIL PROTECTED]
This really should be fixed before 4.3.0-dev is released..
[2002-10-13 19:24:37] [EMAIL PROTECTED]
I may be experiencing a related problem with php.ini. It seems PHP does
not recognize subdirectories (Windows only?). For example, the
following is OK:
include_path = ".;C:\PHPinc;C:\Templates"
and the following is not OK:
include_path = ".;C:\PHPinc;C:\PHPinc\Templates"
I am running:
PHP 4.2.3
Windows 2000 Pro
Apache 1.3.27
Mod_SSL 2.8.11
OpenSSL 0.9.6g
[2002-10-01 10:35:20] [EMAIL PROTECTED]
DO NOT open more bug reports about this SAME issue.
Thank you.
The remainder of the comments for this report are too long. To view
the rest of the comments, please view the bug report online at
http://bugs.php.net/19689
--
Edit this bug report at http://bugs.php.net/?id=19689&edit=1
#20610 [NEW]: mail() does not work on Windows 95, but does work on Win2000
From: [EMAIL PROTECTED] Operating system: Windows 95 PHP version: 4.3.0RC1 PHP Bug Type: Mail related Bug description: mail() does not work on Windows 95, but does work on Win2000 Mail() function does not work on Win95. Seems to me it simply doesn't call sendmail stub. PHP.ini: sendmail_path = z:/usr/sbin/sendmail -t -i test.php: z:/usr/sbin/sendmail.exe is a debug stub. It reads STDIN and put data to the file (tested OK on Win2000 & Win95 from command line). On Win2000 all works correctly, promlems are only on Windows 95. -- Edit bug report at http://bugs.php.net/?id=20610&edit=1 -- Try a CVS snapshot: http://bugs.php.net/fix.php?id=20610&r=trysnapshot Fixed in CVS: http://bugs.php.net/fix.php?id=20610&r=fixedcvs Fixed in release: http://bugs.php.net/fix.php?id=20610&r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=20610&r=needtrace Try newer version: http://bugs.php.net/fix.php?id=20610&r=oldversion Not developer issue:http://bugs.php.net/fix.php?id=20610&r=support Expected behavior: http://bugs.php.net/fix.php?id=20610&r=notwrong Not enough info:http://bugs.php.net/fix.php?id=20610&r=notenoughinfo Submitted twice:http://bugs.php.net/fix.php?id=20610&r=submittedtwice register_globals: http://bugs.php.net/fix.php?id=20610&r=globals PHP 3 support discontinued: http://bugs.php.net/fix.php?id=20610&r=php3 Daylight Savings: http://bugs.php.net/fix.php?id=20610&r=dst IIS Stability: http://bugs.php.net/fix.php?id=20610&r=isapi
#20610 [Bgs]: mail() does not work on Windows 95, but does work on Win2000
ID: 20610 User updated by: [EMAIL PROTECTED] Reported By: [EMAIL PROTECTED] Status: Bogus Bug Type: Mail related Operating System: Windows 95 PHP Version: 4.3.0RC1 New Comment: It's a very strange thing, because on Win2000 all works correctly. What's the difference between Win95 and Win2000 in the stage of opening process streams?.. You see that popen() works in both OSes. By the way, I didn't find in the documentation direct (!) instruction, that sendmail_path does not work on Windows. Maybe it's a documentation problem?.. Previous Comments: [2002-11-24 12:29:55] [EMAIL PROTECTED] Sorry, but your problem does not imply a bug in PHP itself. For a list of more appropriate places to ask for help using PHP, please visit http://www.php.net/support.php as this bug system is not the appropriate forum for asking support questions. Thank you for your interest in PHP. On windows PHP connects directly to the SMTP specified via the SMTP ini setting, the sendmail_path is only used on UNIX based systems. [2002-11-24 10:38:43] [EMAIL PROTECTED] Mail() function does not work on Win95. Seems to me it simply doesn't call sendmail stub. PHP.ini: sendmail_path = z:/usr/sbin/sendmail -t -i test.php: z:/usr/sbin/sendmail.exe is a debug stub. It reads STDIN and put data to the file (tested OK on Win2000 & Win95 from command line). On Win2000 all works correctly, promlems are only on Windows 95. -- Edit this bug report at http://bugs.php.net/?id=20610&edit=1
#20487 [Fbk->Csd]: mod_php crashes under Apache 1.3.27 & MaxRequestsPerChild=infinite
ID: 20487 User updated by: [EMAIL PROTECTED] Reported By: [EMAIL PROTECTED] -Status: Feedback +Status: Closed Bug Type: Reproducible crash Operating System: Windows 2000 PHP Version: 4.3.0RC1 New Comment: RC2 seems to be OK. Thanks. Previous Comments: [2002-11-28 05:05:16] [EMAIL PROTECTED] Please test with RC2. Or preferrably with the latest STABLE snapshot from http://snaps.php.net [2002-11-27 15:07:59] [EMAIL PROTECTED] I think we can move this Report to "closed" because it seems to be fixed in RC2 (-> I haven't tried under heavy load) I've tried with 2,4 and even 100 Frames ;-) Apache and Apache2 didn't crash. mfg DMIII [2002-11-22 18:09:32] [EMAIL PROTECTED] i've experienced this same bug with 4.3.0RC1 (Apache 2.0.43 on Windows XP Pro (Service Pack 1)... In my experience it seems to recurr randomly, but the logic presented here, does hold true. I've also witnessed similar crashes with 4.2.4-dev, but 4.3 does it far more frequently.. Presumably as long as two requests are going on at the same time.. it doesn't have to be from the same origin.. [2002-11-21 09:24:59] [EMAIL PROTECTED] There is the same Problem with Apache2 (2.0.43) and PHP 4.3.0RC1!! [2002-11-21 06:14:17] [EMAIL PROTECTED] The more frames you load the earlier the bug occours! I've tried with 4 frames -> 2xReload and it crashes! The remainder of the comments for this report are too long. To view the rest of the comments, please view the bug report online at http://bugs.php.net/20487 -- Edit this bug report at http://bugs.php.net/?id=20487&edit=1
#21390 [NEW]: php.exe does not work - needs Kernel32.dll::CancelIo
From: [EMAIL PROTECTED] Operating system: Windows 95 PHP version: 4.3.0 PHP Bug Type: Reproducible crash Bug description: php.exe does not work - needs Kernel32.dll::CancelIo PHP.exe (45056 bytes) does not work on Win95. It imports CancelIo from Kernel32.dll, but this routine does not exist in Kernel32 on Windows 95! Previous version (4.2.3) works correctly. There is nothing about it in PHP documentation and install.txt, maybe documenation problem? P.S. mod_php under Apache works OK. CLI version works too. There is only non-CLI php.exe 4.3.0 problem. -- Edit bug report at http://bugs.php.net/?id=21390&edit=1 -- Try a CVS snapshot: http://bugs.php.net/fix.php?id=21390&r=trysnapshot Fixed in CVS: http://bugs.php.net/fix.php?id=21390&r=fixedcvs Fixed in release: http://bugs.php.net/fix.php?id=21390&r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=21390&r=needtrace Try newer version: http://bugs.php.net/fix.php?id=21390&r=oldversion Not developer issue:http://bugs.php.net/fix.php?id=21390&r=support Expected behavior: http://bugs.php.net/fix.php?id=21390&r=notwrong Not enough info:http://bugs.php.net/fix.php?id=21390&r=notenoughinfo Submitted twice:http://bugs.php.net/fix.php?id=21390&r=submittedtwice register_globals: http://bugs.php.net/fix.php?id=21390&r=globals PHP 3 support discontinued: http://bugs.php.net/fix.php?id=21390&r=php3 Daylight Savings: http://bugs.php.net/fix.php?id=21390&r=dst IIS Stability: http://bugs.php.net/fix.php?id=21390&r=isapi Install GNU Sed:http://bugs.php.net/fix.php?id=21390&r=gnused
#19549 [NEW]: 4.1.0 -> 4.2.2 "include" operator incompatibility
From: [EMAIL PROTECTED] Operating system: Windows PHP version: 4.2.2 PHP Bug Type: Unknown/Other Function Bug description: 4.1.0 -> 4.2.2 "include" operator incompatibility PHP v4.2.0+ (Windows): include "/home/some/site.php"; - DOES NOT work (try to believe)! We have to use instead: include "z:/home/some/site.php"; # bad... Bad?.. BAD!!! Previous PHP v4.1.0: include "/home/some/site.php"; - works correct. I think that since 4.2.0 pathes like "/some/where" does not treated as absolute. For example, if we add "z:" to "include_path", include "/home/some/site.php" become workable - it is only the prove. It is VERY loathsome bug, because it makes Windows scripts incompatible with Unix and with previous PHP versions. P.S. DocumentRoot "/home/site/www" ... GET http://site/test.php - DOES NOT work too. It seems to me mod_php uses the same "include" function while starting the script. -- Edit bug report at http://bugs.php.net/?id=19549&edit=1 -- Try a CVS snapshot: http://bugs.php.net/fix.php?id=19549&r=trysnapshot Fixed in CVS:http://bugs.php.net/fix.php?id=19549&r=fixedcvs Fixed in release:http://bugs.php.net/fix.php?id=19549&r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=19549&r=needtrace Try newer version: http://bugs.php.net/fix.php?id=19549&r=oldversion Not developer issue: http://bugs.php.net/fix.php?id=19549&r=support Expected behavior: http://bugs.php.net/fix.php?id=19549&r=notwrong Not enough info: http://bugs.php.net/fix.php?id=19549&r=notenoughinfo Submitted twice: http://bugs.php.net/fix.php?id=19549&r=submittedtwice register_globals:http://bugs.php.net/fix.php?id=19549&r=globals
#19549 [Bgs]: 4.1.0 -> 4.2.2 "include" operator incompatibility
ID: 19549 User updated by: [EMAIL PROTECTED] Reported By: [EMAIL PROTECTED] Status: Bogus Bug Type: Unknown/Other Function Operating System: Windows -PHP Version: 4.2.2 +PHP Version: 4.2.3 New Comment: Unfortunately, new version (4.2.3) has THE SAME bug: Z:\!distrib\php-4.2.3-Win32>php.exe ^Z Warning: Failed opening '/test.php' for inclusion (include_path='.;c:\php4\pear') in - on line 2 If I use "include 'z:/test.php'", it works. Help! Previous Comments: [2002-09-22 20:29:06] [EMAIL PROTECTED] Thank you for taking the time to report a problem with PHP. Unfortunately you are not using a current version of PHP -- the problem might already be fixed. Please download a new PHP version from http://www.php.net/downloads.php If you are able to reproduce the bug with one of the latest versions of PHP, please change the PHP version on this bug report to the version you tested and change the status back to "Open". Again, thank you for your continued support of PHP. [2002-09-22 07:13:36] [EMAIL PROTECTED] PHP v4.2.0+ (Windows): include "/home/some/site.php"; - DOES NOT work (try to believe)! We have to use instead: include "z:/home/some/site.php"; # bad... Bad?.. BAD!!! Previous PHP v4.1.0: include "/home/some/site.php"; - works correct. I think that since 4.2.0 pathes like "/some/where" does not treated as absolute. For example, if we add "z:" to "include_path", include "/home/some/site.php" become workable - it is only the prove. It is VERY loathsome bug, because it makes Windows scripts incompatible with Unix and with previous PHP versions. P.S. DocumentRoot "/home/site/www" ... GET http://site/test.php - DOES NOT work too. It seems to me mod_php uses the same "include" function while starting the script. -- Edit this bug report at http://bugs.php.net/?id=19549&edit=1
#19650 [NEW]: 4.2.3 (!) "include" operator mistake
From: [EMAIL PROTECTED] Operating system: Windows PHP version: 4.2.3 PHP Bug Type: Unknown/Other Function Bug description: 4.2.3 (!) "include" operator mistake I'm trying to write here again (maybe previous thread is down?). You said before this bug in NOT actual in 4.2.3, but code STILL DOES NOT work in 4.2.3. So, PHP v4.2.0 (and later) on Windows: include "/home/some/site.php"; - DOES NOT work (try to believe)! We have to use instead: include "z:/home/some/site.php"; # bad... Bad?.. BAD!!! Previous PHP v4.1.0: include "/home/some/site.php"; - works correct. I think that since 4.2.0 pathes like "/some/where" does not treated as absolute. For example, if we add "z:" to "include_path", include "/home/some/site.php" become workable - it is only the prove. It is VERY loathsome bug, because it makes Windows scripts incompatible with Unix and with previous PHP versions. Again, new version (4.2.3) has THE SAME bug: Z:\!distrib\php-4.2.3-Win32>php.exe ^Z Warning: Failed opening '/test.php' for inclusion (include_path='.;c:\php4\pear') in - on line 2 If I use "include 'z:/test.php'", it works. Please help (our clients are very angry!) P.S. DocumentRoot "/home/site/www" ... GET http://site/test.php - DOES NOT work too. It seems to me mod_php uses the same "include" function while starting the script. -- Edit bug report at http://bugs.php.net/?id=19650&edit=1 -- Try a CVS snapshot: http://bugs.php.net/fix.php?id=19650&r=trysnapshot Fixed in CVS:http://bugs.php.net/fix.php?id=19650&r=fixedcvs Fixed in release:http://bugs.php.net/fix.php?id=19650&r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=19650&r=needtrace Try newer version: http://bugs.php.net/fix.php?id=19650&r=oldversion Not developer issue: http://bugs.php.net/fix.php?id=19650&r=support Expected behavior: http://bugs.php.net/fix.php?id=19650&r=notwrong Not enough info: http://bugs.php.net/fix.php?id=19650&r=notenoughinfo Submitted twice: http://bugs.php.net/fix.php?id=19650&r=submittedtwice register_globals:http://bugs.php.net/fix.php?id=19650&r=globals
#19650 [Fbk->Opn]: 4.2.3 (!) "include" operator mistake
ID: 19650 User updated by: [EMAIL PROTECTED] Reported By: [EMAIL PROTECTED] -Status: Feedback +Status: Open Bug Type: Unknown/Other Function Operating System: Windows PHP Version: 4.2.3 New Comment: Version http://snaps.php.net/win32/php4-win32-latest.zip STILL DOES NOT WORK (z:/test.php contains "echo '!'"): Z:\!distrib\aaa>php.exe ^Z ! Z:\!distrib\aaa>php.exe ^Z Warning: main(/test.php) [http://www.php.net/function.main]: failed to create stream: No such file or directory in Z:\!distrib\aaa\- on line 2 Warning: Failed opening '/test.php' for inclusion (include_path='.;c:\php4\pear') in Z:\!dis trib\aaa\- on line 2 Previous Comments: [2002-09-28 23:01:54] [EMAIL PROTECTED] Please try using this CVS snapshot: http://snaps.php.net/php4-latest.tar.gz For Windows: http://snaps.php.net/win32/php4-win32-latest.zip [2002-09-28 11:23:53] [EMAIL PROTECTED] I'm trying to write here again (maybe previous thread is down?). You said before this bug in NOT actual in 4.2.3, but code STILL DOES NOT work in 4.2.3. So, PHP v4.2.0 (and later) on Windows: include "/home/some/site.php"; - DOES NOT work (try to believe)! We have to use instead: include "z:/home/some/site.php"; # bad... Bad?.. BAD!!! Previous PHP v4.1.0: include "/home/some/site.php"; - works correct. I think that since 4.2.0 pathes like "/some/where" does not treated as absolute. For example, if we add "z:" to "include_path", include "/home/some/site.php" become workable - it is only the prove. It is VERY loathsome bug, because it makes Windows scripts incompatible with Unix and with previous PHP versions. Again, new version (4.2.3) has THE SAME bug: Z:\!distrib\php-4.2.3-Win32>php.exe ^Z Warning: Failed opening '/test.php' for inclusion (include_path='.;c:\php4\pear') in - on line 2 If I use "include 'z:/test.php'", it works. Please help (our clients are very angry!) P.S. DocumentRoot "/home/site/www" ... GET http://site/test.php - DOES NOT work too. It seems to me mod_php uses the same "include" function while starting the script. -- Edit this bug report at http://bugs.php.net/?id=19650&edit=1
#19689 [NEW]: 4.2.3 and higher "include" operator mistake
From: [EMAIL PROTECTED] Operating system: Windows PHP version: 4CVS-2002-10-01 PHP Bug Type: Unknown/Other Function Bug description: 4.2.3 and higher "include" operator mistake I'm trying to write here THIRD time (maybe previous two threads is down?). You said before this bug in NOT actual in 4.2.3 and in CVS snapshot: http://snaps.php.net/win32/php4-win32-latest.zip but code STILL DOES NOT work in 4.2.3 and 4.3.0-dev. So, PHP v4.2.0 (and later!) on Windows: include "/home/some/site.php"; - DOES NOT work (try to believe)! We have to use instead: include "z:/home/some/site.php"; # bad... Bad?.. BAD!!! Previous PHP v4.1.0: include "/home/some/site.php"; - works correct. I think that since 4.2.0 pathes like "/some/where" does not treated as absolute. For example, if we add "z:" to "include_path", include "/home/some/site.php" become workable - it is only the prove. It is VERY loathsome bug, because it makes Windows scripts incompatible with Unix and with previous PHP versions. Again, new version (4.3.0) has THE SAME bug: Z:\!distrib\php-4.2.3-Win32>php.exe ^Z Warning: Failed opening '/test.php' for inclusion (include_path='.;c:\php4\pear') in - on line 2 If I use "include 'z:/test.php'", it works. Please help (our clients are very angry!) P.S. DocumentRoot "/home/site/www" ... GET http://site/test.php - DOES NOT work too. It seems to me mod_php uses the same "include" function while starting the script. P.P.S. I'm not a nasty man, but I would write here again if you continue ignore these messages like previous two. Generally speaking, good luck & thank you for PHP as such. -- Edit bug report at http://bugs.php.net/?id=19689&edit=1 -- Try a CVS snapshot: http://bugs.php.net/fix.php?id=19689&r=trysnapshot Fixed in CVS:http://bugs.php.net/fix.php?id=19689&r=fixedcvs Fixed in release:http://bugs.php.net/fix.php?id=19689&r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=19689&r=needtrace Try newer version: http://bugs.php.net/fix.php?id=19689&r=oldversion Not developer issue: http://bugs.php.net/fix.php?id=19689&r=support Expected behavior: http://bugs.php.net/fix.php?id=19689&r=notwrong Not enough info: http://bugs.php.net/fix.php?id=19689&r=notenoughinfo Submitted twice: http://bugs.php.net/fix.php?id=19689&r=submittedtwice register_globals:http://bugs.php.net/fix.php?id=19689&r=globals
#19689 [Bgs]: 4.2.3 and higher "include" operator mistake
ID: 19689 User updated by: [EMAIL PROTECTED] Reported By: [EMAIL PROTECTED] Status: Bogus Bug Type: Unknown/Other Function Operating System: Windows PHP Version: 4CVS-2002-10-01 New Comment: OK, if you cannot correct your own program without misleading words (you said before TWICE that there is no bug, and it is the ONLY thing disagreeable to me), get it: php-4.2.3/TSRM/tsrm_virtual_cwd.h, line 56: - #define IS_ABSOLUTE_PATH(path, len) \ - (len >= 2 && isalpha(path[0]) && path[1] == ':') + #define IS_ABSOLUTE_PATH(path, len) \ + (len >= 2 && isalpha(path[0]) && path[1] == ':') \ + || (len >= 1 && IS_SLASH(path[0])) This section is under #ifdef TSRM_WIN32 block (of course). I'm not a specialist in PHP core, so I have spent about an hour to find bug location. Unfortunately I CANNOT stop on that, because our users still download PHP from your site. I will be very glad if you correct this bug in the next version (4.3.0 I suppose?). Previous Comments: [2002-10-01 08:06:18] [EMAIL PROTECTED] Oh, I forgot: http://www.derickrethans.nl/20020426.php [2002-10-01 08:03:43] [EMAIL PROTECTED] Please do not submit the same bug more than once. An existing bug report already describes this very problem. Even if you feel that your issue is somewhat different, the resolution is likely to be the same. Because of this, we hope you add your comments to the original bug instead. Thank you for your interest in PHP. [2002-10-01 08:02:52] [EMAIL PROTECTED] I'm trying to write here THIRD time (maybe previous two threads is down?). You said before this bug in NOT actual in 4.2.3 and in CVS snapshot: http://snaps.php.net/win32/php4-win32-latest.zip but code STILL DOES NOT work in 4.2.3 and 4.3.0-dev. So, PHP v4.2.0 (and later!) on Windows: include "/home/some/site.php"; - DOES NOT work (try to believe)! We have to use instead: include "z:/home/some/site.php"; # bad... Bad?.. BAD!!! Previous PHP v4.1.0: include "/home/some/site.php"; - works correct. I think that since 4.2.0 pathes like "/some/where" does not treated as absolute. For example, if we add "z:" to "include_path", include "/home/some/site.php" become workable - it is only the prove. It is VERY loathsome bug, because it makes Windows scripts incompatible with Unix and with previous PHP versions. Again, new version (4.3.0) has THE SAME bug: Z:\!distrib\php-4.2.3-Win32>php.exe ^Z Warning: Failed opening '/test.php' for inclusion (include_path='.;c:\php4\pear') in - on line 2 If I use "include 'z:/test.php'", it works. Please help (our clients are very angry!) P.S. DocumentRoot "/home/site/www" ... GET http://site/test.php - DOES NOT work too. It seems to me mod_php uses the same "include" function while starting the script. P.P.S. I'm not a nasty man, but I would write here again if you continue ignore these messages like previous two. Generally speaking, good luck & thank you for PHP as such. -- Edit this bug report at http://bugs.php.net/?id=19689&edit=1
#19689 [Bgs]: 4.2.3 and higher "include" operator mistake
ID: 19689 User updated by: [EMAIL PROTECTED] Reported By: [EMAIL PROTECTED] Status: Bogus Bug Type: Unknown/Other Function Operating System: Windows PHP Version: 4CVS-2002-10-01 New Comment: OK, if you cannot correct your own program without misleading words (you said before TWICE that there is no bug, and it is the ONLY thing disagreeable to me), get it: php-4.2.3/TSRM/tsrm_virtual_cwd.h, line 56: - #define IS_ABSOLUTE_PATH(path, len) \ - (len >= 2 && isalpha(path[0]) && path[1] == ':') + #define IS_ABSOLUTE_PATH(path, len) \ + (len >= 2 && isalpha(path[0]) && path[1] == ':') \ + || (len >= 1 && IS_SLASH(path[0])) This section is under #ifdef TSRM_WIN32 block (of course). I'm not a specialist in PHP core, so I have spent about an hour to find bug location. Unfortunately I CANNOT stop on that, because our users still download PHP from your site. I will be very glad if you correct this bug in the next version (4.3.0 I suppose?). Previous Comments: [2002-10-01 08:58:28] [EMAIL PROTECTED] OK, if you cannot correct your own program without misleading words (you said before TWICE that there is no bug, and it is the ONLY thing disagreeable to me), get it: php-4.2.3/TSRM/tsrm_virtual_cwd.h, line 56: - #define IS_ABSOLUTE_PATH(path, len) \ - (len >= 2 && isalpha(path[0]) && path[1] == ':') + #define IS_ABSOLUTE_PATH(path, len) \ + (len >= 2 && isalpha(path[0]) && path[1] == ':') \ + || (len >= 1 && IS_SLASH(path[0])) This section is under #ifdef TSRM_WIN32 block (of course). I'm not a specialist in PHP core, so I have spent about an hour to find bug location. Unfortunately I CANNOT stop on that, because our users still download PHP from your site. I will be very glad if you correct this bug in the next version (4.3.0 I suppose?). [2002-10-01 08:06:18] [EMAIL PROTECTED] Oh, I forgot: http://www.derickrethans.nl/20020426.php [2002-10-01 08:03:43] [EMAIL PROTECTED] Please do not submit the same bug more than once. An existing bug report already describes this very problem. Even if you feel that your issue is somewhat different, the resolution is likely to be the same. Because of this, we hope you add your comments to the original bug instead. Thank you for your interest in PHP. [2002-10-01 08:02:52] [EMAIL PROTECTED] I'm trying to write here THIRD time (maybe previous two threads is down?). You said before this bug in NOT actual in 4.2.3 and in CVS snapshot: http://snaps.php.net/win32/php4-win32-latest.zip but code STILL DOES NOT work in 4.2.3 and 4.3.0-dev. So, PHP v4.2.0 (and later!) on Windows: include "/home/some/site.php"; - DOES NOT work (try to believe)! We have to use instead: include "z:/home/some/site.php"; # bad... Bad?.. BAD!!! Previous PHP v4.1.0: include "/home/some/site.php"; - works correct. I think that since 4.2.0 pathes like "/some/where" does not treated as absolute. For example, if we add "z:" to "include_path", include "/home/some/site.php" become workable - it is only the prove. It is VERY loathsome bug, because it makes Windows scripts incompatible with Unix and with previous PHP versions. Again, new version (4.3.0) has THE SAME bug: Z:\!distrib\php-4.2.3-Win32>php.exe ^Z Warning: Failed opening '/test.php' for inclusion (include_path='.;c:\php4\pear') in - on line 2 If I use "include 'z:/test.php'", it works. Please help (our clients are very angry!) P.S. DocumentRoot "/home/site/www" ... GET http://site/test.php - DOES NOT work too. It seems to me mod_php uses the same "include" function while starting the script. P.P.S. I'm not a nasty man, but I would write here again if you continue ignore these messages like previous two. Generally speaking, good luck & thank you for PHP as such. -- Edit this bug report at http://bugs.php.net/?id=19689&edit=1
#19689 [Opn]: 4.2.3 and higher "include" operator mistake
ID: 19689 User updated by: [EMAIL PROTECTED] Reported By: [EMAIL PROTECTED] Status: Open Bug Type: Unknown/Other Function Operating System: Windows PHP Version: 4CVS-2002-10-01 New Comment: All I want is only to make this bug "open", but not "bogus". Now it is all right. Thank you. Previous Comments: [2002-10-01 09:09:34] [EMAIL PROTECTED] Hello, A lot of people work very hard on PHP for no money, there is a general etiquette which is advisable to stick to when reporting a bug and that is to be nice. Now I havnt looked at your other reports personally and I dont know why they were marked as bogus (perhaps someone was tired, could not understand exactly what you mean or for many other reasons) and I appolgize for that, a better way to approach it is to ask why the bug has been marked as bogus rather than ranting that it has. We deal with many bugs each day and have limited time thus those that get fixed are those which either are highly important to us (If Im affected by a bug Ill fix it myself I wont expect other people too) or one that affects a lot of people. Remember you have not paid for PHP and are asking us to do work for you for free. Now you have spent an hour fixing that bug and Ill have a look at the patch now check it fixes it and does not break anything else and if that is the case then it will be applied before the next version and I thank you for your time, but I promise you it will still use up at least 20 mins of my time (and IMHO my time is more important to me than your time is). So what I am saying is that yes you have a bug in PHP you want fixed but dont expect it to happen straight away, localizing and fixing a bug and checking its implications is a slow and boring game and we dont always get it right but we do it for free so have a touch more patience with us and we are likley to be more helpful. Sorry to rant. - James [2002-10-01 08:58:29] [EMAIL PROTECTED] OK, if you cannot correct your own program without misleading words (you said before TWICE that there is no bug, and it is the ONLY thing disagreeable to me), get it: php-4.2.3/TSRM/tsrm_virtual_cwd.h, line 56: - #define IS_ABSOLUTE_PATH(path, len) \ - (len >= 2 && isalpha(path[0]) && path[1] == ':') + #define IS_ABSOLUTE_PATH(path, len) \ + (len >= 2 && isalpha(path[0]) && path[1] == ':') \ + || (len >= 1 && IS_SLASH(path[0])) This section is under #ifdef TSRM_WIN32 block (of course). I'm not a specialist in PHP core, so I have spent about an hour to find bug location. Unfortunately I CANNOT stop on that, because our users still download PHP from your site. I will be very glad if you correct this bug in the next version (4.3.0 I suppose?). [2002-10-01 08:58:28] [EMAIL PROTECTED] OK, if you cannot correct your own program without misleading words (you said before TWICE that there is no bug, and it is the ONLY thing disagreeable to me), get it: php-4.2.3/TSRM/tsrm_virtual_cwd.h, line 56: - #define IS_ABSOLUTE_PATH(path, len) \ - (len >= 2 && isalpha(path[0]) && path[1] == ':') + #define IS_ABSOLUTE_PATH(path, len) \ + (len >= 2 && isalpha(path[0]) && path[1] == ':') \ + || (len >= 1 && IS_SLASH(path[0])) This section is under #ifdef TSRM_WIN32 block (of course). I'm not a specialist in PHP core, so I have spent about an hour to find bug location. Unfortunately I CANNOT stop on that, because our users still download PHP from your site. I will be very glad if you correct this bug in the next version (4.3.0 I suppose?). [2002-10-01 08:06:18] [EMAIL PROTECTED] Oh, I forgot: http://www.derickrethans.nl/20020426.php [2002-10-01 08:03:43] [EMAIL PROTECTED] Please do not submit the same bug more than once. An existing bug report already describes this very problem. Even if you feel that your issue is somewhat different, the resolution is likely to be the same. Because of this, we hope you add your comments to the original bug instead. Thank you for your interest in PHP. The remainder of the comments for this report are too long. To view the rest of the comments, please view the bug report online at http://bugs.php.net/19689 -- Edit this bug report at http://bugs.php.net/?id=19689&edit=1
#19650 [Com]: 4.2.3 (!) "include" operator mistake
ID: 19650 Comment by: [EMAIL PROTECTED] Reported By: [EMAIL PROTECTED] Status: Bogus Bug Type: Scripting Engine problem Operating System: Windows PHP Version: 4.2.3 New Comment: New information about this bug. 1. Since version PHP 4.2.3 bug is "changed": File /t.php AND ./t.php (identical): Tests: a) > php.exe c:\t.php - works b) > php.exe \t.php - works c) > php.exe /t.php - works d) > php.exe ^Z - DOES NOT work. In version 4.1.2...4.2.2 a, b & c are not working. 2. Versions <= 4.1.1 work correctly. So, I think there is only an error if PHP.exe v4.2.3+ gets program from STDIN. Previous versions (<4.2.3) do not work with command-line filename too. Previous Comments: [2002-10-01 10:49:52] [EMAIL PROTECTED] A) same problem b) same submitter -> bogus [2002-10-01 10:42:38] [EMAIL PROTECTED] Dup not bogus [2002-10-01 10:33:38] [EMAIL PROTECTED] Please do not submit the same bug more than once. An existing bug report already describes this very problem. Even if you feel that your issue is somewhat different, the resolution is likely to be the same. Because of this, we hope you add your comments to the original bug instead. Thank you for your interest in PHP. The other report of yours, #19689, has more information so closing this.. [2002-09-30 06:28:36] [EMAIL PROTECTED] Version http://snaps.php.net/win32/php4-win32-latest.zip STILL DOES NOT WORK (z:/test.php contains "echo '!'"): Z:\!distrib\aaa>php.exe ^Z ! Z:\!distrib\aaa>php.exe ^Z Warning: main(/test.php) [http://www.php.net/function.main]: failed to create stream: No such file or directory in Z:\!distrib\aaa\- on line 2 Warning: Failed opening '/test.php' for inclusion (include_path='.;c:\php4\pear') in Z:\!dis trib\aaa\- on line 2 [2002-09-28 23:01:54] [EMAIL PROTECTED] Please try using this CVS snapshot: http://snaps.php.net/php4-latest.tar.gz For Windows: http://snaps.php.net/win32/php4-win32-latest.zip The remainder of the comments for this report are too long. To view the rest of the comments, please view the bug report online at http://bugs.php.net/19650 -- Edit this bug report at http://bugs.php.net/?id=19650&edit=1
#19650 [Bgs]: 4.2.3 (!) "include" operator mistake
ID: 19650 User updated by: [EMAIL PROTECTED] Reported By: [EMAIL PROTECTED] Status: Bogus Bug Type: Scripting Engine problem Operating System: Windows PHP Version: 4.2.3 New Comment: Of course, not OK (-; File c:\t.php: File c:\test.php: c:\php> php.exe -q < c:\t.php Warning: Failed opening '/test.php' for inclusion (include_path='.;c:\php4\pear') in - on line 2 c:\php> php.exe -q c:\t.php ! Strange, isn't it?.. Good "/test.php", or not good, when I write DocumentRoot /home/localhost/www in httpd.conf, and then GET /phpinfo.php HTTP/1.1 Apache calls /home/localhost/www/phpinfo.php, but not ./home/localhost/www (-; Well, 4.2.3 processes it correctly (and we may close this bug report), but... I meant that PHP 4.2.3 still have something wrong in its code, because absolute-slashed pathes do not work sometimes (like in "< script", maybe somewhere else?). Here, in Russia, we saying in such cases: "Heh, something's wrong in Danish kingdom". (-; Today I tried to debug it, but have not found a bug place. Maybe next time. Good luck. Previous Comments: [2002-10-05 16:07:37] [EMAIL PROTECTED] is not good this is better: ok? [2002-10-05 15:35:28] [EMAIL PROTECTED] New information about this bug. 1. Since version PHP 4.2.3 bug is "changed": File /t.php AND ./t.php (identical): Tests: a) > php.exe c:\t.php - works b) > php.exe \t.php - works c) > php.exe /t.php - works d) > php.exe ^Z - DOES NOT work. In version 4.1.2...4.2.2 a, b & c are not working. 2. Versions <= 4.1.1 work correctly. So, I think there is only an error if PHP.exe v4.2.3+ gets program from STDIN. Previous versions (<4.2.3) do not work with command-line filename too. [2002-10-01 10:49:52] [EMAIL PROTECTED] A) same problem b) same submitter -> bogus [2002-10-01 10:42:38] [EMAIL PROTECTED] Dup not bogus [2002-10-01 10:33:38] [EMAIL PROTECTED] Please do not submit the same bug more than once. An existing bug report already describes this very problem. Even if you feel that your issue is somewhat different, the resolution is likely to be the same. Because of this, we hope you add your comments to the original bug instead. Thank you for your interest in PHP. The other report of yours, #19689, has more information so closing this.. The remainder of the comments for this report are too long. To view the rest of the comments, please view the bug report online at http://bugs.php.net/19650 -- Edit this bug report at http://bugs.php.net/?id=19650&edit=1
#19650 [Bgs->Opn]: 4.2.3 (!) "include" operator mistake
ID: 19650
User updated by: [EMAIL PROTECTED]
Reported By: [EMAIL PROTECTED]
-Status: Bogus
+Status: Open
Bug Type: Scripting Engine problem
Operating System: Windows
PHP Version: 4.2.3
New Comment:
Wow... I'm a fool, I have tested wrong PHP version! Error is still
actual.
But now I think I have found the bug place.
File main/fopen_wrappers.c, in function php_fopen_with_path, we can see
a piece of code:
if (IS_ABSOLUTE_PATH(filename, filename_length)) {
if ((php_check_safe_mode_include_dir(filename TSRMLS_CC)) == 0)
/* filename is in safe_mode_include_dir (or subdir) */
return php_fopen_and_set_opened_path(filename, mode, opened_path
TSRMLS_CC);
if (PG(safe_mode) && (!php_checkuid(filename, mode,
CHECKUID_CHECK_MODE_PARAM)))
return NULL;
return php_fopen_and_set_opened_path(filename, mode, opened_path
TSRMLS_CC);
}
/* else start to glue path from include_path */
...
Under Windows IS_ABSOLUTE_PATH is:
#define IS_ABSOLUTE_PATH(path, len) \
(len >= 2 && isalpha(path[0]) && path[1] == ':')
Of course, when Apache's mod_php4 makes "include" request for
"/home/localhost/www/phpinfo.php", program DOES NOT get into "if"
statement! And we get pathes something like
".//home/localhost/www/phpinfo.php" and
"c:/php/pear//home/localhost/www/phpinfo.php" when
include_path=".;c:/php/pear" (I have dumped "path" argument of
virtual_fopen function [tsrm_virtual-cwd.c] to watch such pathes).
We cannot modify IS_ABSOLUTE_PATH macro, because there is #define
COPY_WHEN_ABSOLUTE 2 before it, and core always think that "absolute"
part contains 2 characters - we'd like to thank developers of windows
port for that :-(. Path "/some/path" contains NONE "absolute"
characters ("z:/some/path" contains two - "z:").
But, if we patch:
- if (IS_ABSOLUTE_PATH(filename, filename_length)) {
+ if (IS_ABSOLUTE_PATH(filename, filename_length)
+ || IS_SLASH(*filename)) {
PHP begins to work!
I don't know would it cause a security problem with safe_mode. Code is
too tangled and duplicated (somebody likes "copy+paste" technique of
programming, I suppose).
Please correct this bug in next PHPs. Now I will patch it "by hands",
but I don't want our users to cry when they would install newer version
and it begin to trash.
Previous Comments:
[2002-10-05 18:49:02] [EMAIL PROTECTED]
Of course, not OK (-;
File c:\t.php:
File c:\test.php:
c:\php> php.exe -q < c:\t.php
Warning: Failed opening '/test.php' for inclusion
(include_path='.;c:\php4\pear') in - on line 2
c:\php> php.exe -q c:\t.php
!
Strange, isn't it?..
Good "/test.php", or not good, when I write
DocumentRoot /home/localhost/www
in httpd.conf, and then
GET /phpinfo.php HTTP/1.1
Apache calls /home/localhost/www/phpinfo.php, but not
./home/localhost/www (-; Well, 4.2.3 processes it correctly (and we may
close this bug report), but...
I meant that PHP 4.2.3 still have something wrong in its code, because
absolute-slashed pathes do not work sometimes (like in "< script",
maybe somewhere else?). Here, in Russia, we saying in such cases: "Heh,
something's wrong in Danish kingdom". (-; Today I tried to debug it,
but have not found a bug place. Maybe next time.
Good luck.
[2002-10-05 16:07:37] [EMAIL PROTECTED]
is not good
this is better:
ok?
[2002-10-05 15:35:28] [EMAIL PROTECTED]
New information about this bug.
1. Since version PHP 4.2.3 bug is "changed":
File /t.php AND ./t.php (identical):
Tests:
a) > php.exe c:\t.php - works
b) > php.exe \t.php - works
c) > php.exe /t.php - works
d) > php.exe
^Z
- DOES NOT work.
In version 4.1.2...4.2.2 a, b & c are not working.
2. Versions <= 4.1.1 work correctly.
So, I think there is only an error if PHP.exe v4.2.3+ gets program from
STDIN. Previous versions (<4.2.3) do not work with command-line
filename too.
[2002-10-01 10:49:52] [EMAIL PROTECTED]
A) same problem b) same submitter -> bogus
[2002-10-01 10:42:38] [EMAIL PROTECTED]
Dup not bogus
The remainder of the comments for this report are too long. To view
the rest of the comments, please view the bug report online at
http://bugs.php.net/19650
--
Edit this bug report at http://bugs.php.net/?id=19650&edit=1
#19650 [NoF->Csd]: 4.2.3 (!) "include" operator mistake
ID: 19650
User updated by: [EMAIL PROTECTED]
Reported By: [EMAIL PROTECTED]
-Status: No Feedback
+Status: Closed
Bug Type: Scripting Engine problem
Operating System: Windows
PHP Version: 4.2.3
New Comment:
OK, today's snapshot (27 0ct 2002) seems to be correct:
z:/t.php:
z:/test.php:
Z:\!distrib\php\php4-win32-latest>php.exe /t.php
!
Thanks. But I suppose that this bug is deeply rooted. When I make PHP
to read a script from STDIN:
Z:\!distrib\php\php4-win32-latest>php.exe
^Z
Warning: main(/test.php) [http://www.php.net/function.main]: failed to
create stream: No such file or directory in
Z:\!distrib\php\php4-win32-latest\- on line 2
Warning: Failed opening '/test.php' for inclusion
(include_path='.;c:\php4\pear') in Z:\!dis
trib\php\php4-win32-latest\- on line 2
Of course,
Z:\!distrib\php\php4-win32-latest>php.exe
^Z
!
Previous Comments:
[2002-10-27 19:11:06] [EMAIL PROTECTED]
No feedback was provided. The bug is being suspended because
we assume that you are no longer experiencing the problem.
If this is not the case and you are able to provide the
information that was requested earlier, please do so and
change the status of the bug back to "Open". Thank you.
[2002-10-12 10:26:26] [EMAIL PROTECTED]
Please try using this CVS snapshot:
http://snaps.php.net/php4-latest.tar.gz
For Windows:
http://snaps.php.net/win32/php4-win32-latest.zip
[2002-10-07 12:18:47] [EMAIL PROTECTED]
Wow... I'm a fool, I have tested wrong PHP version! Error is still
actual.
But now I think I have found the bug place.
File main/fopen_wrappers.c, in function php_fopen_with_path, we can see
a piece of code:
if (IS_ABSOLUTE_PATH(filename, filename_length)) {
if ((php_check_safe_mode_include_dir(filename TSRMLS_CC)) == 0)
/* filename is in safe_mode_include_dir (or subdir) */
return php_fopen_and_set_opened_path(filename, mode, opened_path
TSRMLS_CC);
if (PG(safe_mode) && (!php_checkuid(filename, mode,
CHECKUID_CHECK_MODE_PARAM)))
return NULL;
return php_fopen_and_set_opened_path(filename, mode, opened_path
TSRMLS_CC);
}
/* else start to glue path from include_path */
...
Under Windows IS_ABSOLUTE_PATH is:
#define IS_ABSOLUTE_PATH(path, len) \
(len >= 2 && isalpha(path[0]) && path[1] == ':')
Of course, when Apache's mod_php4 makes "include" request for
"/home/localhost/www/phpinfo.php", program DOES NOT get into "if"
statement! And we get pathes something like
".//home/localhost/www/phpinfo.php" and
"c:/php/pear//home/localhost/www/phpinfo.php" when
include_path=".;c:/php/pear" (I have dumped "path" argument of
virtual_fopen function [tsrm_virtual-cwd.c] to watch such pathes).
We cannot modify IS_ABSOLUTE_PATH macro, because there is #define
COPY_WHEN_ABSOLUTE 2 before it, and core always think that "absolute"
part contains 2 characters - we'd like to thank developers of windows
port for that :-(. Path "/some/path" contains NONE "absolute"
characters ("z:/some/path" contains two - "z:").
But, if we patch:
- if (IS_ABSOLUTE_PATH(filename, filename_length)) {
+ if (IS_ABSOLUTE_PATH(filename, filename_length)
+ || IS_SLASH(*filename)) {
PHP begins to work!
I don't know would it cause a security problem with safe_mode. Code is
too tangled and duplicated (somebody likes "copy+paste" technique of
programming, I suppose).
Please correct this bug in next PHPs. Now I will patch it "by hands",
but I don't want our users to cry when they would install newer version
and it begin to trash.
[2002-10-05 18:49:02] [EMAIL PROTECTED]
Of course, not OK (-;
File c:\t.php:
File c:\test.php:
c:\php> php.exe -q < c:\t.php
Warning: Failed opening '/test.php' for inclusion
(include_path='.;c:\php4\pear') in - on line 2
c:\php> php.exe -q c:\t.php
!
Strange, isn't it?..
Good "/test.php", or not good, when I write
DocumentRoot /home/localhost/www
in httpd.conf, and then
GET /phpinfo.php HTTP/1.1
Apache calls /home/localhost/www/phpinfo.php, but not
./home/localhost/www (-; Well, 4.2.3 processes it correctly (and we may
close this bug report), but...
I meant that PHP 4.2.3 still have something wrong in its code, because
absolute-slashed pathes do not work sometimes (like in "< script",
maybe somewhere else?). Here, in Russia, we saying in such cases: "Heh,
something's wrong in Danish kingdom". (-; Today I tried to debug it,
but have not found a bug place. Maybe next time.
Good luck.
[2002-10-05 16:07:37] [EMAIL PROTECTED]
is not good
this is better:
ok?
-
#25547 [Ver]: error_handler and array index with function call
ID: 25547
Updated by: [EMAIL PROTECTED]
Reported By: cschneid at cschneid dot com
Status: Verified
Bug Type: Zend Engine 2 problem
Operating System: *
-PHP Version: 5CVS,4CVS
+PHP Version: 4CVS
New Comment:
The bug is fixed in PHP5 CVS (zend.c,v 1.260).
Previous Comments:
[2003-10-16 04:09:39] [EMAIL PROTECTED]
You now have a memory leak. I tried something similar too. But we
decided to look for a better solution where we don't gc the variable we
still need.
[2003-10-15 08:19:08] cschneid at cschneid dot com
The problem seems to be that dim->value is overwritten, copying the
value solves this. I don't have enough insight in Zend to know if this
is a memory leak and the values should be freed at some point or if
this is ok.
Hope this helps:
diff -u -u -r1.316.2.21 zend_execute.c
--- Zend/zend_execute.c 30 Jul 2003 16:33:54 - 1.316.2.21
+++ Zend/zend_execute.c 15 Oct 2003 12:17:10 -
@@ -626,7 +626,7 @@
offset_key_length = 0;
goto fetch_string_dim;
case IS_STRING:
- offset_key = dim->value.str.val;
+ offset_key = estrndup(dim->value.str.val,
dim->value.str.len);
offset_key_length = dim->value.str.len;
fetch_string_dim:
[2003-09-15 13:37:55] cschneid at cschneid dot com
Description:
Error handler seems to destroy array indices if called due
to a undefined array index generated by a function.
Reproduce code:
---
function handler($errno, $errstr, $errfile, $errline)
{
$test = "aaa";
}
set_error_handler('handler');
$output[trim("bbb")]++;
print_r($output);
Expected result:
Array
(
[bbb] => 1
)
Actual result:
--
Array
(
[aaa] => 1
)
--
Edit this bug report at http://bugs.php.net/?id=25547&edit=1
#32776 [Opn]: SOAP doesn't support one-way operations
ID: 32776 Updated by: [EMAIL PROTECTED] Reported By: [EMAIL PROTECTED] Status: Open Bug Type: SOAP related Operating System: Any PHP Version: 5CVS-2005-04-20 (dev) -Assigned To: +Assigned To: dmitry New Comment: Fixed in CVS HEAD and PHP_5_0 Previous Comments: [2005-04-20 12:27:50] [EMAIL PROTECTED] Description: One-way operations are not supported by ext/soap Such operation must return HTTP "202 Accepted" response without content. -- Edit this bug report at http://bugs.php.net/?id=32776&edit=1
#32776 [Opn->Csd]: SOAP doesn't support one-way operations
ID: 32776 Updated by: [EMAIL PROTECTED] Reported By: [EMAIL PROTECTED] -Status: Open +Status: Closed Bug Type: SOAP related Operating System: Any PHP Version: 5CVS-2005-04-20 (dev) Assigned To: dmitry Previous Comments: [2005-04-20 12:59:34] [EMAIL PROTECTED] Fixed in CVS HEAD and PHP_5_0 [2005-04-20 12:27:50] [EMAIL PROTECTED] Description: One-way operations are not supported by ext/soap Such operation must return HTTP "202 Accepted" response without content. -- Edit this bug report at http://bugs.php.net/?id=32776&edit=1
#32455 [Asn->Fbk]: wrong setting property to unseted value
ID: 32455
Updated by: [EMAIL PROTECTED]
Reported By: becicka at aarongroup dot cz
-Status: Assigned
+Status: Feedback
Bug Type:SOAP related
PHP Version: 5CVS-2005-03-31
Assigned To: dmitry
New Comment:
I need to look into WSDL file to understand the bug.
Can you email it to me.
Previous Comments:
[2005-04-03 18:25:11] [EMAIL PROTECTED]
Assigning to the maintainer.
[2005-04-01 10:58:10] becicka at aarongroup dot cz
I try this (http://snaps.php.net/php5-latest.tar.gz) and there are the
same situation.
[2005-03-25 23:34:17] [EMAIL PROTECTED]
Please try using this CVS snapshot:
http://snaps.php.net/php5-latest.tar.gz
For Windows:
http://snaps.php.net/win32/php5-win32-latest.zip
[2005-03-25 15:17:10] becicka at aarongroup dot cz
Description:
When I set a object property to unseted variable and than I call a SOAP
function with this paramater, I get message
Fatal error: SOAP-ERROR: Encoding: object hasn't 'name' property .
Reproduce code:
---
class Passenger {
var $name;
}
$wsdl =& new SoapClient(WSDL_LOCATION, array("trace" => 1, 'exceptions'
=> 0));
$p = new Passenger;
/* if ($xyz === null) $xyz = null; //if here is this row, it's works
fine otherwise calling SOAP function failed */
$p->name = $xyz;//$xyz is not set!!!
$wsdl->setPassenger($p); //call SOAP function failed
--
Edit this bug report at http://bugs.php.net/?id=32455&edit=1
#29944 [Asn->Csd]: Function defined in switch, crashes
ID: 29944 Updated by: [EMAIL PROTECTED] Reported By: norxh at binnews dot com -Status: Assigned +Status: Closed Bug Type: Reproducible crash Operating System: * PHP Version: 5CVS-2005-03-07 Assigned To: andi New Comment: Fixed in CVS HEAD, PHP_5_0, PHP_4_3. PHP_4_3 seems already had fix for this problem but improper one. Previous Comments: [2005-04-23 23:31:29] tingle at virtuanews dot co dot uk I have just tried this with the latest CVS (after spending 4 hours bug finding!). This bug is still in CVS. Exactly the same as is shown here, the following will crash apache: This crashes both apache 1 and apache 2 on windows xp, macosx and linux based systems. I was testing on the CVS from 23/04/05. [2005-04-02 12:05:10] dmhouse at gmail dot com I have a reduced test case for this bug. Things necessary for Apache to segfault: * The function must be defined inside a case statement that is executed. * A variable must be set to a value within the function. * The function must be called. I'm running PHP 5.0.3 (built from source, but I doubt that matters) on Apache 2. Bug is reproducible through Apache and through CLI. [2005-03-04 15:17:24] kameshj at fastmail dot fm Problem is in CG(switch_cond_stack) that is shared by two op_arrays(One which has original switch and another one being the function declararion inside a case). Case 1 op_array of foo ZEND_ECHO ZEND_FETCH_CONSTANT ZEND_RETURN ZEND_HANDLE_EXCEPTION Case 2(Segfault case) op_array of foo ZEND_ECHO ZEND_FETCH_CONSTANT ZEND_SWITCH_FREE ZEND_RETURN ZEND_HANDLE_EXCEPTION In Case 2 ZEND_SWITCH_FREE opcode is getting included in the function foo's op_array. This is done by zend_do_return in zend_compile.c with the following code zend_stack_apply(&CG(switch_cond_stack), ZEND_STACK_APPLY_TOPDOWN, (int (*)(void *element)) generate_free_switch_expr); In zend_do_return of foo of Case 2, While executing zend_stack_apply, CG(switch_cond_stack) has 2 entries as follows, foo's seperator dummy switch_cond(at top) main op_array's switch case(at bottom) "main op_array's switch case(at bottom)" is generating ZEND_SWITCH_FREE opcode. I feel the switch_cond_stack to be op_array specific rather than keeping it at compiler_globals as it is now. [2004-12-16 21:18:18] edwin at phpfreakz dot nl I didn't have any problems with declaring functions in a switch statement with Apache 2/PHP 5.0.1, but after installing PHP 5.0.3 php crashes. You don't get any errors, it just doesn't work. I'm using Windows XP Pro with SP2. [2004-11-10 15:53:24] sami at sipponen dot com This code crashes PHP 5.1.0-DEV Windows Version. The remainder of the comments for this report are too long. To view the rest of the comments, please view the bug report online at http://bugs.php.net/29944 -- Edit this bug report at http://bugs.php.net/?id=29944&edit=1
#32429 [Ver->Csd]: method_exists() always return TRUE if __call method exists
ID: 32429
Updated by: [EMAIL PROTECTED]
Reported By: pasha dot zubkov at gmail dot com
-Status: Verified
+Status: Closed
Bug Type: Zend Engine 2 problem
Operating System: Linux 2.6.11-grsec
PHP Version: 5CVS-2005-03-29 (dev)
New Comment:
Fixed in CVS HEAD.
Previous Comments:
[2005-03-29 07:49:51] pasha dot zubkov at gmail dot com
Any solution for this bag?
[2005-03-24 14:20:44] pasha dot zubkov at gmail dot com
I checkout HEAD from cvs. Problem not solved.
[2005-03-24 00:27:55] [EMAIL PROTECTED]
Confirmed with HEAD only.
[2005-03-23 23:58:44] [EMAIL PROTECTED]
Please try using this CVS snapshot:
http://snaps.php.net/php5-latest.tar.gz
For Windows:
http://snaps.php.net/win32/php5-win32-latest.zip
[2005-03-23 14:43:34] pasha dot zubkov at gmail dot com
Description:
See example. I can't use `if (method_exists()) {}` because it always
return TRUE
Reproduce code:
---
test();
}
}
public function __call($name, $args) {
throw new Exception('Call to undefined method
'.get_class($this).'::'.$name.'()');
}
}
try {
$test = new TestClass;
} catch (Exception $e) {
exit($e->getMessage());
}
?>
Expected result:
bool(false)
Actual result:
--
bool(true) Call to undefined method TestClass::test()
--
Edit this bug report at http://bugs.php.net/?id=32429&edit=1
#30702 [Asn->Csd]: cannot initialize class variable from class constant
ID: 30702 Updated by: [EMAIL PROTECTED] Reported By: douglass_davis at earthlink dot net -Status: Assigned +Status: Closed Bug Type: Zend Engine 2 problem Operating System: * PHP Version: 5CVS-2005-03-07 Assigned To: andi New Comment: Fixed in CVS HEAD and PHP_5_0. Previous Comments: [2005-03-07 21:49:07] [EMAIL PROTECTED] Does not work with latest HEAD nor latest PHP_5_0 [2005-02-16 12:14:34] php at kaiundina dot de seems to be the same Problem occuring at a slightly different place: Bug #31601 [2004-11-17 20:54:39] [EMAIL PROTECTED] It doesn't work with latest PHP 5.1 here: Fatal error: Cannot access self:: when no class scope is active in C:\cygwin\home\Nuno\kk.php on line 21 [2004-11-16 12:22:25] [EMAIL PROTECTED] Please try using this CVS snapshot: http://snaps.php.net/php5-STABLE-latest.tar.gz For Windows: http://snaps.php.net/win32/php5.0-win32-latest.zip Works fine here. [2004-11-11 17:25:04] [EMAIL PROTECTED] I think this was supposed to work.. The remainder of the comments for this report are too long. To view the rest of the comments, please view the bug report online at http://bugs.php.net/30702 -- Edit this bug report at http://bugs.php.net/?id=30702&edit=1
#32427 [Asn->Csd]: Interfaces not allowed access modifiers
ID: 32427 Updated by: [EMAIL PROTECTED] Reported By: jason at amp-design dot net -Status: Assigned +Status: Closed Bug Type: Zend Engine 2 problem Operating System: Cent OS 3 PHP Version: 5CVS-2005-03-23 (dev) Assigned To: andi New Comment: Fixed in CVS HEAD. Previous Comments: [2005-04-18 17:31:31] jason at amp-design dot net It appears in the later CVS versions of PHP that this bug seems to have gone. It appears to be fixed (maybe someone double check, and close it) [2005-03-30 18:51:12] [EMAIL PROTECTED] Assigning to Andi, as he's the author of this change: http://cvs.php.net/diff.php/ZendEngine2/zend_compile.c?php=69434a7f33b2b7d3cc6152f95b1a307f&r1=1.596&r2=1.597&ty=u [2005-03-23 13:27:27] jason at amp-design dot net Description: In the 5.1.0 branch (this morning's build), there seems to be a problem with interfaces and static methods. If a method is declared as static, it raises an error. Upon removing the public static keywords from the interface, I get an error because the class implementing this interface has a different signature / declaraton from the interface, Thus meaning static members are a no-no with interfaces. This was tested on this morning's snapshot build of 5.1.0. I assume that this is a bug and not some daft change in behavoiour you want to push into the 5.1.x branch of PHP as it would break a lot of existing PHP5 code. Reproduce code: --- Expected result: I am a silly error Actual result: -- Fatal error: Access type for interface method Example::sillyError() must be omitted in /data/web/tools/iq_framework/test.php on line 4 -- Edit this bug report at http://bugs.php.net/?id=32427&edit=1
#30889 [Asn->Csd]: Conflict between __get/__set and ++ operator
ID: 30889
Updated by: [EMAIL PROTECTED]
Reported By: m dot gehin at adan dot asso dot fr
-Status: Assigned
+Status: Closed
Bug Type: Zend Engine 2 problem
Operating System: winxp
PHP Version: 5CVS-2005-03-08
Assigned To: andi
New Comment:
Fixed in CVS HEAD and PHP_5_0
Previous Comments:
[2005-04-05 21:54:03] [EMAIL PROTECTED]
Andi, is it supposed to work so or not?
I.e. is it a docu problem or a bug?
[2005-03-09 19:02:42] m dot gehin at adan dot asso dot fr
Unfortunately this snapshot doesn't solve the problem
Snapshot version :
Sun, 06 Mar 2005 20:50:26 +0100
Version: 5.1.0-dev
Branch: HEAD
Build: Release_TS
[2005-03-06 18:28:46] [EMAIL PROTECTED]
Please try using this CVS snapshot:
http://snaps.php.net/php5-latest.tar.gz
For Windows:
http://snaps.php.net/win32/php5-win32-latest.zip
[2004-11-25 00:39:59] m dot gehin at adan dot asso dot fr
Description:
When using the ++ operator on a property that is overloaded, the value
inside the class is incremented *BEFORE* the call to the __set()
method.
Reproduce code:
---
class overloaded
{
private $values;
function __construct()
{
$this->values = array('a' => 0);
}
function __set($name, $value)
{
print "set $name = $value ($name was
".$this->values[$name].")";
$this->values[$name] = $value;
}
function __get($name)
{
print "get $name (returns ".$this->values[$name].")";
return $this->values[$name];
}
}
$test = new overloaded();
$test->a++; // __get(), then __set()
Expected result:
get a (returns 0)
set a = 1 (a was 0)
Actual result:
--
get a (returns 0)
set a = 1 (a was 1)
--
Edit this bug report at http://bugs.php.net/?id=30889&edit=1
#32674 [Asn]: exception in iterator causes crash
ID: 32674
Updated by: [EMAIL PROTECTED]
Reported By: rashid at ds dot pg dot gda dot pl
Status: Assigned
Bug Type: Zend Engine 2 problem
Operating System: *
PHP Version: 5CVS-2005-04-11
Assigned To: andi
New Comment:
Fixed in CVS HEAD and PHP_5_0.
Previous Comments:
[2005-04-12 10:30:25] [EMAIL PROTECTED]
The illegal opcde error can be produced easily. Actually no iterator
method that throws an exception doesn't result in direct script
termination in case of try/catch block absence. This said a much easier
test case is the following:
--TEST--
Bug #32674 (exception in iterator causes crash).
--FILE--
dummy = 'this will crash';
exit(0);
?>
===DONE===
--EXPECTF--
Unfortunatley even handling exceptions for all method calls in FE_RESET
and FE_FETCH opcode doesn't help since then SWITCH_FREE still ignores
the exception.
In the end it seems that this is an error where either the executor
loop needs to check for the exceptions or the lw level function handler
needs to do a direct long jump on exceptions (the latter is bad because
it doesn't free anything and ha problems with catch blocks).
[2005-04-11 17:50:34] [EMAIL PROTECTED]
I get this:
Fatal error: Invalid opcode 137/1/8. in /home/jani/t.php on line 50
[2005-04-11 17:26:08] rashid at ds dot pg dot gda dot pl
Description:
If you create class implementing Iterator interface and exception
happens during foreach than hell breaks loose. After exception in
foreach debugger shows, that processing is continued in line after the
loop. In this situation exception should be thrown further. Instead it
looks like exception is being kept somewhere while processing continues
and is being thrown at end of the script (end of scope?).
Normally (ie. operations on non-objects) this doesn`t cause crash, but
if you assign object member after interrupted loop, then apache dies
(1.3.28).
Apart from latest shapshot the problem is present also in 5.0.3, didn`t
check 5.0.4.
Reproduce code:
---
_elements);
}
public function count() {
return count($this->_elements);
}
public function current() {
$element = current($this->_elements);
return $element;
}
public function next() {
$element = next($this->_elements);
return $element;
}
public function key() {
$this->_fillCollection();
$element = key($this->_elements);
return $element;
}
public function valid() {
throw new Exception('shit happend');
return ($this->current() !== false);
}
}
class class2 {
public $dummy;
}
$obj = new class2();
$col = new collection();
$dummy = 'nothing';
foreach($col as $co) {
//irrelevant
}
echo 'shouldn`t get here';
//$dummy = 'this will not crash';
$obj->dummy = 'this will crash';
?>
Expected result:
Fatal error: Uncaught exception 'Exception' with message 'shit happend'
in d:\projects\opcapp\htdocs\collcrash.php:35 Stack trace: #0
d:\projects\opcapp\htdocs\collcrash.php(35): collection::valid() #1
d:\projects\opcapp\htdocs\collcrash.php(49): collection::valid() #2
d:\projects\opcapp\htdocs\collcrash.php(49): unknown() #3 {main} thrown
in d:\projects\opcapp\htdocs\collcrash.php on line 35
Actual result:
--
apache crash
or (if you comment out the bottom line and remove comment from the one
above it)
shouldn`t get here
Fatal error: Uncaught exception 'Exception' with message 'shit happend'
in d:\projects\opcapp\htdocs\collcrash.php:35 Stack trace: #0
d:\projects\opcapp\htdocs\collcrash.php(35): collection::valid() #1
d:\projects\opcapp\htdocs\collcrash.php(49): collection::valid() #2
d:\projects\opcapp\htdocs\collcrash.php(49): unknown() #3 {main} thrown
in d:\projects\opcapp\htdocs\collcrash.php on line 35
--
Edit this bug report at http://bugs.php.net/?id=32674&edit=1
#32674 [Asn->Csd]: exception in iterator causes crash
ID: 32674
Updated by: [EMAIL PROTECTED]
Reported By: rashid at ds dot pg dot gda dot pl
-Status: Assigned
+Status: Closed
Bug Type: Zend Engine 2 problem
Operating System: *
PHP Version: 5CVS-2005-04-11
Assigned To: andi
Previous Comments:
[2005-04-27 08:47:42] [EMAIL PROTECTED]
Fixed in CVS HEAD and PHP_5_0.
[2005-04-12 10:30:25] [EMAIL PROTECTED]
The illegal opcde error can be produced easily. Actually no iterator
method that throws an exception doesn't result in direct script
termination in case of try/catch block absence. This said a much easier
test case is the following:
--TEST--
Bug #32674 (exception in iterator causes crash).
--FILE--
dummy = 'this will crash';
exit(0);
?>
===DONE===
--EXPECTF--
Unfortunatley even handling exceptions for all method calls in FE_RESET
and FE_FETCH opcode doesn't help since then SWITCH_FREE still ignores
the exception.
In the end it seems that this is an error where either the executor
loop needs to check for the exceptions or the lw level function handler
needs to do a direct long jump on exceptions (the latter is bad because
it doesn't free anything and ha problems with catch blocks).
[2005-04-11 17:50:34] [EMAIL PROTECTED]
I get this:
Fatal error: Invalid opcode 137/1/8. in /home/jani/t.php on line 50
[2005-04-11 17:26:08] rashid at ds dot pg dot gda dot pl
Description:
If you create class implementing Iterator interface and exception
happens during foreach than hell breaks loose. After exception in
foreach debugger shows, that processing is continued in line after the
loop. In this situation exception should be thrown further. Instead it
looks like exception is being kept somewhere while processing continues
and is being thrown at end of the script (end of scope?).
Normally (ie. operations on non-objects) this doesn`t cause crash, but
if you assign object member after interrupted loop, then apache dies
(1.3.28).
Apart from latest shapshot the problem is present also in 5.0.3, didn`t
check 5.0.4.
Reproduce code:
---
_elements);
}
public function count() {
return count($this->_elements);
}
public function current() {
$element = current($this->_elements);
return $element;
}
public function next() {
$element = next($this->_elements);
return $element;
}
public function key() {
$this->_fillCollection();
$element = key($this->_elements);
return $element;
}
public function valid() {
throw new Exception('shit happend');
return ($this->current() !== false);
}
}
class class2 {
public $dummy;
}
$obj = new class2();
$col = new collection();
$dummy = 'nothing';
foreach($col as $co) {
//irrelevant
}
echo 'shouldn`t get here';
//$dummy = 'this will not crash';
$obj->dummy = 'this will crash';
?>
Expected result:
Fatal error: Uncaught exception 'Exception' with message 'shit happend'
in d:\projects\opcapp\htdocs\collcrash.php:35 Stack trace: #0
d:\projects\opcapp\htdocs\collcrash.php(35): collection::valid() #1
d:\projects\opcapp\htdocs\collcrash.php(49): collection::valid() #2
d:\projects\opcapp\htdocs\collcrash.php(49): unknown() #3 {main} thrown
in d:\projects\opcapp\htdocs\collcrash.php on line 35
Actual result:
--
apache crash
or (if you comment out the bottom line and remove comment from the one
above it)
shouldn`t get here
Fatal error: Uncaught exception 'Exception' with message 'shit happend'
in d:\projects\opcapp\htdocs\collcrash.php:35 Stack trace: #0
d:\projects\opcapp\htdocs\collcrash.php(35): collection::valid() #1
d:\projects\opcapp\htdocs\collcrash.php(49): collection::valid() #2
d:\projects\opcapp\htdocs\collcrash.php(49): unknown() #3 {main} thrown
in d:\projects\opcapp\htdocs\collcrash.php on line 35
--
Edit this bug report at http://bugs.php.net/?id=32674&edit=1
#32833 [Ver->Csd]: Invalid opcode
ID: 32833 Updated by: [EMAIL PROTECTED] Reported By: jason at amp-design dot net -Status: Verified +Status: Closed Bug Type: Zend Engine 2 problem Operating System: CentOS 4 / RHEL 3 PHP Version: 5CVS-2005-04-26 (dev) New Comment: Fixed in CVS HEAD. Previous Comments: [2005-04-26 15:55:58] jason at amp-design dot net I don't know what is defined by 'HEAD', but I have I have tested this bug on older versions of of the PHP 5.1 branch admittedly they are only a week or so old, as well as the latest snapshot and I get the same problem. It doesn't happen on 5.0.4 or older. HOWEVER... older versions of PHP also have inconsistent behavior, as the test code surely should display a notice / warning... much like produces a notice on version 5.0.4 and probably other older versions. [2005-04-26 13:28:34] [EMAIL PROTECTED] Confirmed with HEAD only. [2005-04-26 12:11:57] jason at amp-design dot net Description: Trying to concatenate on to a new/empty array element with the array push assignment operator, [] =, causes PHP to create a fatal error. This is tested with the CVS snapshot http://snaps.php.net/php5-200504260830.tar.gz Although the code I have given below is technically not correct because you can not concatenate a string on to an empty/new array element, it should be seen as an warning and not a fatal error (See notes on expected result). Also, the error is not very descriptive from a end user's point of view. I assume the invalid opcode error is obviously a generic error message that is used by you guys at Zend for debugging. Previous versions of PHP seem to inconsistent. The reproducable code doesn't even give me a warning message when tested under PHP5.0.4. Surely it would be right to make this consistent with concatenating an undefined variable, by making a "Notice: Undefined variable: test[]" error. Reproduce code: --- Expected result: Some form of warning stating that you can not concatenate to an empty/undefined array element. This should be consistent with the fact that if you did... that you would get a warning message because $f has not been defined before. (i.e. Notice: Undefined variable: f) Actual result: -- Fatal error: Invalid opcode 30/16/8 -- Edit this bug report at http://bugs.php.net/?id=32833&edit=1
#29104 [Asn->Csd]: Function declaration in method doesn't work
ID: 29104
Updated by: [EMAIL PROTECTED]
Reported By: tomas_matousek at hotmail dot com
-Status: Assigned
+Status: Closed
Bug Type: Zend Engine 2 problem
Operating System: *
PHP Version: 5CVS-2005-03-06
Assigned To: andi
New Comment:
Fixed in CVS HEAD and PHP_5_0.
Previous Comments:
[2005-03-25 15:14:21] php at trancer dot nl
Mind you that such code _IS_ working PHP4 so it is breaking BC and not
listed on http://www.zend.com/manual/migration5.incompatible.php
As to why it could be useful.. to do recursion and not register a
function in global scope. (Of course there are methods for this
aswell.)
[2005-03-06 20:39:03] [EMAIL PROTECTED]
Assigned to the mastah..
[2004-12-30 15:29:19] ulderico at maber dot com dot br
OH! In time! Just to reinforce the first and the second paragraph of my
last comment.
Why would you create a function that should be invoked JUST ONCE?
Initialize environment? It makes no point. You can do it directly in
the code, using "if" to distinguish any situation of environment that
one may have.
[2004-12-30 15:16:42] ulderico at maber dot com dot br
IMHO, Nested Functions are BAD&WRONG, thus they should be disabled.
Firstly, when you DECLARE a function inside a function, you have a
redeclaration problem. Try to execute the parent function twice and
most likely you'll receive a message: "Fatal error: Cannot redeclare
".
OK! Some may dispute: "let's create an undeclare_function() so as to
allow at the end of the function undeclare the child function. It would
enable to reinvoke the parent function whenever we like". Well, THIS IS
ALSO B&R. Why would you undeclare a function that you're going to use?
Secondly, if a function needs to work in a closed (encapsuled)
environment, well, I think you need a CLASS, not a function. In a class
you may have a public, private or protected variables invoked by either
public, private or protected methods.
Thusly, a code like this (sorry the indentation, I want to save
space):
class A
{
function b(){}
function c(){}
function d(){}
function g(){
echo "function g - begin\n";
function f(){echo "function f\n";}
echo "function g - end\n";
}
}
should be written like this:
class A
{
function b(){}
function c(){}
function d(){}
function g(){
echo "function g - begin\n";
f::f();
echo "function g - end\n";
}
}
class f{
function f(){echo "function f\n";}
}
$obj = new A();
$obj->g();
So, the rationale is, why you need to have function within function if
you've got classes?
[2004-08-14 01:24:12] [EMAIL PROTECTED]
While nested functions are maybe useful feature for someone declaration
of a function inside the body of a method (which happens to be a
function inside a class) is _ambigious_ . Why? There is no reserved
word "method" for marking methods of a class and "function" is used so
when it is between {} after class name "function" creates a method of
the class. IMO "function" inside a method should not be possible.
The remainder of the comments for this report are too long. To view
the rest of the comments, please view the bug report online at
http://bugs.php.net/29104
--
Edit this bug report at http://bugs.php.net/?id=29104&edit=1
#29210 [Asn->Csd]: Function: is_callable - no support for private and protected classes
ID: 29210 Updated by: [EMAIL PROTECTED] Reported By: freeload at softhome dot net -Status: Assigned +Status: Closed Bug Type: Zend Engine 2 problem Operating System: * PHP Version: 5CVS-2005-03-07 Assigned To: andi New Comment: Fixed in CVS HEAD and PHP_5_0. Previous Comments: [2005-03-07 20:12:01] [EMAIL PROTECTED] Andi, check the patch please. [2004-08-29 06:53:25] [EMAIL PROTECTED] This patch should fix the bug: http://tony2001.phpclub.net/dev/tmp/is_callable.diff test file: http://tony2001.phpclub.net/dev/tmp/is_callable.phpt [2004-07-16 15:07:46] freeload at softhome dot net Description: The built in function is_callable, does not return false, on unreachable functions like protected and private ones. Reproduce code: --- Expected result: bool(false) bool(false) Actual result: -- bool(true) bool(true) -- Edit this bug report at http://bugs.php.net/?id=29210&edit=1
#29015 [Ver->Csd]: Incorrect behavior of member vars(non string ones)-numeric mem vars und others
ID: 29015
Updated by: [EMAIL PROTECTED]
Reported By: tomas_matousek at hotmail dot com
-Status: Verified
+Status: Closed
Bug Type: Zend Engine 2 problem
Operating System: *
PHP Version: 5CVS-2005-03-06
New Comment:
Fixed in CVS HEAD and PHP_5_0.
Empty property and string properties started with '\0' are disallowed.
Previous Comments:
[2004-08-14 00:43:06] php at hristov dot com
AFAUK, internally the private member variables are stored in such a way
that the first byte is \0, which maybe you emulate with your test case.
":private" means that the member var is private one.
shorter example for "creating" of a private variable :
php -r '$a=new stdclass();$a->$b=3;var_dump($a);'
and of "integer" member variable
php -r '$a=new stdclass();$b=3;$a->$b=3;var_dump($a);'
andrey
[2004-07-05 15:02:12] tomas_matousek at hotmail dot com
Description:
If I try to use variable with non-string name (e.g.
$x = 10; $$x = ...) the name is converted to a string using standard
conversion rules. That's ok.
But this doesn't work on object's field which is IMHO a bug and it
implies some a buggy behavior.
See the code bellow.
It seems that by:
$x = null;
$a->$x = "whatever";
one can somehow create a private variable (or something like that,
don't know what ":private" means)!
Moreover, there is possibly a bug in get_object_vars when a field name
is a numeric string (e.g. "10") (compare the first item of results of
get_object_vars and var_dump).
Reproduce code:
---
function field_names_test()
{
$a = new stdClass();
$x = 10;
$a->$x = "int(10)";
$x = "10";
$a->$x = "string('10')";
$x = "";
$a->$x = "string('')";
$x = null;
$a->$x = "null";
$x = 1.8;
$a->$x = "double(1.8)";
$x = false;
$a->$x = "bool(false)";
$x = array(1,2,3);
$a->$x = "array(1,2,3)";
var_dump(get_object_vars($a));
var_dump($a);
}
field_names_test();
Expected result:
array(4) {
["10"]=>
string(12) "string('10')"
[""]=>
string(11) "bool(false)"
["1.8"]=>
string(11) "double(1.8)"
["Array"]=>
string(12) "array(1,2,3)"
}
object(stdClass)#1 (4) {
["10"]=>
string(12) "string('10')"
[""]=>
string(11) "bool(false)"
["1.8"]=>
string(11) "double(1.8)"
["Array"]=>
string(12) "array(1,2,3)"
}
Actual result:
--
array(3) {
[10]=>
string(12) "string('10')"
["1.8"]=>
string(11) "double(1.8)"
["Array"]=>
string(12) "array(1,2,3)"
}
object(stdClass)#1 (4) {
["10"]=>
string(12) "string('10')"
[":private"]=>
string(11) "bool(false)"
["1.8"]=>
string(11) "double(1.8)"
["Array"]=>
string(12) "array(1,2,3)"
}
--
Edit this bug report at http://bugs.php.net/?id=29015&edit=1
#32852 [Asn->Csd]: Crash with singleton and __destruct when zend.ze1_compatibility_mode = On
ID: 32852 Updated by: [EMAIL PROTECTED] Reported By: cox at idecnet dot com -Status: Assigned +Status: Closed Bug Type: Zend Engine 2 problem Operating System: * PHP Version: 5CVS-2005-04-29 Assigned To: dmitry New Comment: Fixed in CVS HEAD and PHP_5_0. Previous Comments: [2005-04-29 03:29:29] [EMAIL PROTECTED] Dmitry, if you have time, can you look into these reports with problems with zend.ze1_compatibility_mode? Some of them happen with only PHP_5_0 and some with both it and HEAD. Here's list (this bug excluded): bug #30332 bug #31828 bug #32080 [2005-04-28 16:03:57] cox at idecnet dot com Not using my php.ini doesn't crash in 5.0.4, 5.0.5dev or 5.1cvs and the output match the expected. So investigating my modified settings from the original php.ini-dist, I've found that ze1_compat generates the problem: zend.ze1_compatibility_mode = On (turning it Off does not crash, well, afterall it's php5 only syntax). The other requested data: gcc-3.4.1 bison-1.875 glibc-2.3.3 [2005-04-28 13:52:55] [EMAIL PROTECTED] I still can't reproduce this. I get same result with both HEAD and PHP_5_0 branches and also with the snapshot. Does it give same result if you make sure you don't load any php.ini: sapi/cli/php -n file.php What bison version do you have installed? What compiler (and version) ? [2005-04-28 10:53:13] cox at idecnet dot com With today's CVS (5.1), it does not crash. But the output is: Output: i'm called i'm called i'm called i'm called The __destruct() function is called 4 times. With php5-STABLE-200504271035 (5.0.5dev): $ make distclean $ ./configure \ --prefix=/usr \ --with-config-file-path=/etc/php5 \ --enable-cli \ --disable-cgi \ --disable-pear \ --enable-debug Still the same output and same crash. [2005-04-28 00:25:57] [EMAIL PROTECTED] If you configure with --enable-debug (rm config.cache && ./configure + your options + --enable-debug && make clean && make) does it still crash? Are you sure you ARE using the latest CVS? (the snapshots might not be updated again..) The remainder of the comments for this report are too long. To view the rest of the comments, please view the bug report online at http://bugs.php.net/32852 -- Edit this bug report at http://bugs.php.net/?id=32852&edit=1
#31828 [Ver->Csd]: Crash with zend.ze1_compatibility_mode=On
ID: 31828
Updated by: [EMAIL PROTECTED]
Reported By: jon dot williams at namtec dot co dot uk
-Status: Verified
+Status: Closed
Bug Type: Zend Engine 2 problem
Operating System: *
PHP Version: 5CVS-2005-02-28
New Comment:
Fixed in CVS HEAD and PHP_5_0.
Previous Comments:
[2005-02-28 20:51:50] [EMAIL PROTECTED]
See also bug #32080
[2005-02-03 14:21:59] [EMAIL PROTECTED]
Oh, that was really useful hint, thanks.
Here is the bt:
0x0824fc6e in zend_get_class_entry (zobject=0x84d683c) at
/home/dev/php-src_5_0/Zend/zend_API.c:204
204 if (Z_OBJ_HT_P(zobject)->get_class_entry) {
(gdb) bt
#0 0x0824fc6e in zend_get_class_entry (zobject=0x84d683c) at
/home/dev/php-src_5_0/Zend/zend_API.c:204
#1 0x0827acc1 in zend_assign_to_variable (result=0x84df744,
op1=0x84df758, op2=0x84df76c, value=0x84d683c, type=4,
Ts=0xbfffb310) at /home/dev/php-src_5_0/Zend/zend_execute.c:600
#2 0x0827445d in zend_assign_handler (execute_data=0xbfffd410,
opline=0x84df740, op_array=0x84d643c)
at /home/dev/php-src_5_0/Zend/zend_execute.c:2252
#3 0x082723c8 in execute (op_array=0x84d643c) at
/home/dev/php-src_5_0/Zend/zend_execute.c:1406
#4 0x0824f4ff in zend_execute_scripts (type=8, retval=0x0,
file_count=3) at /home/dev/php-src_5_0/Zend/zend.c:1068
#5 0x08210619 in php_execute_script (primary_file=0xb810) at
/home/dev/php-src_5_0/main/main.c:1630
#6 0x0827dd59 in main (argc=2, argv=0xb8a4) at
/home/dev/php-src_5_0/sapi/cli/php_cli.c:943
#7 0x420157a4 in __libc_start_main () from /lib/tls/libc.so.6
[2005-02-03 14:14:21] jon dot williams at namtec dot co dot uk
Okay, more research - I reverted back to the dist php.ini file and the
crash no longer happens. Regressing through the changes I had made
I've discovered that this crash only happens if PHP 4.x compatibility
is enabled. i.e.
zend.ze1_compatibility_mode = On
[2005-02-03 13:32:40] [EMAIL PROTECTED]
Please try using this CVS snapshot:
http://snaps.php.net/php5-STABLE-latest.tar.gz
For Windows:
http://snaps.php.net/win32/php5.0-win32-latest.zip
Can't reproduce it under Linux with latest snapshot.
[2005-02-03 13:25:41] jon dot williams at namtec dot co dot uk
Description:
Operating System: Windows 2000 Server
PHP Version: 5.0.3 and binary snapshot 200502030930
Apache versions: 2.0.52 and 1.3.31
I am using running the open source CMS system Mambo with the com_events
component. In some circumstances the code in this component would crash
my installation.
After some tracing I narrowed the crash down to a small piece of code
whereby the first element in a singleton array is re-assigned to a
variable name the same as the originating array(See code example).
By reassigning the array element to a new different variable name this
crash can be avoided.
Reproduce code:
---
id = 77;
$o->name = "Aerospace";
$a[] = $o;
$a = $a[0];
print_r($a);
?>
Expected result:
stdClass Object ( [id] => 77 [name] => Aerospace )
Actual result:
--
404 page not found error and Apache logs show a crash where Apache is
forced to restart.
In Apache 2
child process exited with status 3221225477 -- Restarting.
--
Edit this bug report at http://bugs.php.net/?id=31828&edit=1
#32080 [Ver->Csd]: segfault when assigning object to itself with zend.ze1_compatibility_mode=On
ID: 32080
Updated by: [EMAIL PROTECTED]
Reported By: nicoletti at nns dot ch
-Status: Verified
+Status: Closed
Bug Type: Zend Engine 2 problem
Operating System: *
PHP Version: 5CVS-2005-04-29
New Comment:
Fixed in CVS HEAD and PHP_5_0.
Previous Comments:
[2005-02-25 14:59:37] nicoletti at nns dot ch
(gdb) bt
#0 0x081ee835 in zend_std_object_get_class (object=0x836fa74) at
/usr/local/src/php5/php5-200502251330/Zend/zend_object_handlers.c:839
#1 0x081d6e49 in zend_get_class_entry (zobject=0x836fa74) at
/usr/local/src/php5/php5-200502251330/Zend/zend_API.c:227
#2 0x0824fd33 in zend_assign_to_variable (result=0x836e624,
op1=0x836e638, op2=0x836e64c, value=0x836fa74, type=16, Ts=0xbfffd134)
at /usr/local/src/php5/php5-200502251330/Zend/zend_execute.c:861
#3 0x08240d4d in ZEND_ASSIGN_SPEC_CV_CV_HANDLER
(execute_data=0xbfffd1e8) at
/usr/local/src/php5/php5-200502251330/Zend/zend_vm_execute.h:23463
#4 0x081fc2b2 in execute (op_array=0x836a11c) at
/usr/local/src/php5/php5-200502251330/Zend/zend_vm_execute.h:78
#5 0x081d65a9 in zend_execute_scripts (type=8, retval=0x0,
file_count=3) at
/usr/local/src/php5/php5-200502251330/Zend/zend.c:1058
#6 0x08192873 in php_execute_script (primary_file=0xb574) at
/usr/local/src/php5/php5-200502251330/main/main.c:1636
#7 0x08251c7d in main (argc=3, argv=0xb604) at
/usr/local/src/php5/php5-200502251330/sapi/cli/php_cli.c:944
[2005-02-25 14:34:32] [EMAIL PROTECTED]
Please try using this CVS snapshot:
http://snaps.php.net/php5-latest.tar.gz
For Windows:
http://snaps.php.net/win32/php5-win32-latest.zip
[2005-02-23 15:41:27] nicoletti at nns dot ch
Description:
segfault when assigning object to itself in ze1 mode
Reproduce code:
---
ini_set('zend.ze1_compatibility_mode', true);
class test { }
$t = new test;
$t = $t; // gives segfault
Expected result:
last line gives segfault
--
Edit this bug report at http://bugs.php.net/?id=32080&edit=1
#30332 [Asn->Csd]: zend.ze1_compatibility_mode isnt fully compatable with array_push()
ID: 30332 Updated by: [EMAIL PROTECTED] Reported By: justmanj at msu dot edu -Status: Assigned +Status: Closed Bug Type: Zend Engine 2 problem Operating System: * PHP Version: 5.* (2005-04-29) Assigned To: andi New Comment: Fixed in CVS HEAD and PHP_5_0. Previous Comments: [2005-04-16 01:46:06] [EMAIL PROTECTED] Pushing back to Andi (would like to assign to Zeev too but..) [2005-04-13 09:48:21] justmanj at msu dot edu tested with: PHP 5.1.0-dev (cli) (built: Apr 13 2005 08:33:33) Copyright (c) 1997-2005 The PHP Group Zend Engine v2.1.0-dev, Copyright (c) 1998-2004 Zend Technologies zend.ze1_compatibility_mode => On => On produces: C:\php5-win32-latest>php c:\web\ze1_test.php x Object ( [first] => im in the first ) x Object ( ) Array ( [0] => x Object ( [first] => im in the first ) ) which is not the design of php4 j [2004-10-05 23:35:12] justmanj at msu dot edu Description: zend.ze1_compatibility_mode when turned on doesn't honor the same methodlogy as 4.x when passing a class for some parameters - it passes by reference in functions like array_push(); this behavior was not in 4.3.x, and the only workaround is the clone keyword, which should be added in the 4.3.x tree for backwards compatability. Reproduce code: --- first = " im in the first"; print_r($first); print_r($second); print_r($container); Expected result: x Object ( [first] => im in the first ) x Object ( ) Array ( [0] => x Object ( ) ) Actual result: -- x Object ( [first] => im in the first ) x Object ( ) Array ( [0] => x Object ( [first] => im in the first ) ) -- Edit this bug report at http://bugs.php.net/?id=30332&edit=1
#32296 [Asn->Csd]: get_class_methods output has changed between 5.0.2 and 5.0.3
ID: 32296
Updated by: [EMAIL PROTECTED]
Reported By: php dot bug at hebbron dot com
-Status: Assigned
+Status: Closed
Bug Type: Class/Object related
Operating System: *
PHP Version: 5.*
Assigned To: andi
New Comment:
Fixed in CVS HEAD and PHP_5_0.
Now get_class_methods() shows accessible private and protected methods
if it is called from class scope.
Previous Comments:
[2005-03-14 04:46:49] php dot bug at hebbron dot com
Sorry - the expected output is from php 5.0.2 and the actual output is
from 5.0.3 in case that wasn't clear.
[2005-03-14 04:45:09] php dot bug at hebbron dot com
Description:
Using the code below, the output from get_class_methods is different
between versions 5.0.2 and 5.0.3. This missing data is breaking some of
our code. Is this change intended - I can't see it mentioend in the
docs.
Reproduce code:
---
abstract class space{
function __construct(){}
abstract protected function unfold();
}
abstract class shape extends space{
protected final function unfold(){}
}
abstract class quad extends shape{
function buggy(){
$c = get_class($this);
$a = get_class_methods(get_class($this));
$b = get_class_methods($this);
print($c."\n".'a:');
print_r($a);
print('b:');
print_r($b);
}
}
class square extends quad{}
$a = new square();
$a->buggy();
Expected result:
square
a:Array
(
[0] => buggy
[1] => unfold
[2] => __construct
)
b:Array
(
[0] => buggy
[1] => unfold
[2] => __construct
)
Actual result:
--
square
a:Array
(
[0] => buggy
[1] => __construct
)
b:Array
(
[0] => buggy
[1] => __construct
)
--
Edit this bug report at http://bugs.php.net/?id=32296&edit=1
#30707 [Asn->Csd]: Segmentation fault
ID: 30707
Updated by: [EMAIL PROTECTED]
Reported By: guth at fiifo dot u-psud dot fr
-Status: Assigned
+Status: Closed
Bug Type: Zend Engine 2 problem
Operating System: *
PHP Version: 5CVS-2005-04-29
Assigned To: andi
New Comment:
Fixed in CVS HEAD and PHP_5_0
Previous Comments:
[2005-04-29 10:23:15] [EMAIL PROTECTED]
Program received signal SIGSEGV, Segmentation fault.
[Switching to Thread -1208719680 (LWP 31723)]
0x0812c49f in zend_do_fcall_common_helper_SPEC
(execute_data=0xbff2c160) at zend_vm_execute.h:120
120 if (EX(function_state).function->common.fn_flags &
ZEND_ACC_ABSTRACT) {
(gdb) bt
#0 0x0812c49f in zend_do_fcall_common_helper_SPEC
(execute_data=0xbff2c160) at zend_vm_execute.h:120
#1 0x0812c3c9 in execute (op_array=0x8bdd8e4) at zend_vm_execute.h:78
#2 0x0810ea63 in zend_execute_scripts (type=8, retval=0x0,
file_count=3) at /usr/src/php/php5/Zend/zend.c:1059
#3 0x080dcd78 in php_execute_script (primary_file=0xbff2e600) at
/usr/src/php/php5/main/main.c:1653
#4 0x08186a5f in main (argc=2, argv=0xbff2e6c4) at
/usr/src/php/php5/sapi/cli/php_cli.c:954
[2004-12-18 10:38:33] guth at fiifo dot u-psud dot fr
Same bug, different code.
two hours lost :(
The constructor contains a return statement, but it is only
query());
} catch(Exception $e) {
}
}
public function query() {
throw new Exception;
}
}
$test = new UserModuleTest(new UserModuleTest());
?>
[2004-11-10 19:02:50] [EMAIL PROTECTED]
This code is much simplier IMO and demonstrates the same behaviour
(both with 5.0.x & 5.1.x):
byePHP($this->plip());
}
public function byePHP($plop) {
echo "www.haricow.org";
}
public function plip() {
try {
$this->plap($this->plop());
}
catch(Exception $e) {
}
}
public function plap($a) {
}
public function plop() {
throw new Exception;
}
}
new C;
?>
[2004-11-07 00:08:56] guth at fiifo dot u-psud dot fr
Description:
I get another segmentation fault...
You can look at the reproduce code.
Reproduce code:
---
plap($this->plop());
}
catch(Exception $e) {
}
}
public function plap($a) {
}
public function plop() {
throw new Exception;
}
}
class C {
public function __construct() {
$b = new B;
$this->byePHP($b->plip());
}
public function byePHP($plop) {
echo "www.haricow.org";
}
}
new C;
?>
Expected result:
www.haricow.org
Actual result:
--
Program received signal SIGSEGV, Segmentation fault.
[Switching to Thread 1075737248 (LWP 3881)]
0x403d2373 in zend_do_fcall_common_helper
(execute_data=0xbfffccd0, opline=0x8170c64,
op_array=0x816f784)
at /usr/src/php5/Zend/zend_execute.c:2656
2656if
(EX(function_state).function->common.fn_flags &
ZEND_ACC_ABSTRACT) {
(gdb) bt
#0 0x403d2373 in zend_do_fcall_common_helper
(execute_data=0xbfffccd0, opline=0x8170c64,
op_array=0x816f784)
at /usr/src/php5/Zend/zend_execute.c:2656
#1 0x403d2c63 in zend_do_fcall_by_name_handler
(execute_data=0xbfffccd0, opline=0x8170c64,
op_array=0x816f784)
at /usr/src/php5/Zend/zend_execute.c:2825
#2 0x403cebee in execute (op_array=0x816f784) at
/usr/src/php5/Zend/zend_execute.c:1400
#3 0x403d2791 in zend_do_fcall_common_helper
(execute_data=0xbfffce20, opline=0x816b694,
op_array=0x816706c)
at /usr/src/php5/Zend/zend_execute.c:2740
#4 0x403d2c63 in zend_do_fcall_by_name_handler
(execute_data=0xbfffce20, opline=0x816b694,
op_array=0x816706c)
at /usr/src/php5/Zend/zend_execute.c:2825
#5 0x403cebee in execute (op_array=0x816706c) at
/usr/src/php5/Zend/zend_execute.c:1400
#6 0x403a9f5d in zend_execute_scripts (type=8,
retval=0x0, file_count=3)
at /usr/src/php5/Zend/zend.c:1060
#7 0x40362a94 in php_execute_script
(primary_file=0xb190) at
/usr/src/php5/main/main.c:1628
#8 0x403dab14 in apache_php_module_main (r=0x815c29c,
display_source_mode=0)
at /usr/src/php5/sapi/apache/sapi_apache.c:54
#9 0x403dba9f in send_php (r=0x815c29c,
display_source_mode=0, filename=0x815cda4 "/www/test.php")
at /usr/src/php5/sapi/apache/mod_php5.c:622
#10 0x403dbb18 in send_parsed_php (r=0x815c29c) at
/usr/src/php5/sapi/apache/mod
#30162 [Asn->Csd]: Problem with var_dump()
ID: 30162 Updated by: [EMAIL PROTECTED] Reported By: guth at fiifo dot u-psud dot fr -Status: Assigned +Status: Closed Bug Type: Zend Engine 2 problem Operating System: * PHP Version: 5CVS-2005-03-07 Assigned To: andi New Comment: Fixed in CVS HEAD and PHP_5_0. Previous Comments: [2005-03-09 11:33:28] [EMAIL PROTECTED] Nope, this has problably to do with exceptions - not my thing. [2005-03-07 23:52:41] [EMAIL PROTECTED] THink that I broke this... [2004-09-20 09:34:53] guth at fiifo dot u-psud dot fr Description: This bug is linked to bug #30161. var_dump() should produce an object. Reproduce code: --- Expected result: Something like 'Object ...' Actual result: -- UNKNOWN:0 -- Edit this bug report at http://bugs.php.net/?id=30162&edit=1
#30641 [Asn->Csd]: Compile error: error: symbol "zend_error" is used but not defined
ID: 30641 Updated by: [EMAIL PROTECTED] Reported By: hakan at lisas dot de -Status: Assigned +Status: Closed Bug Type: Compile Failure Operating System: Solaris 9 PHP Version: 5CVS-2005-03-25 Assigned To: andi New Comment: Fixed in CVS HEAD. Previous Comments: [2005-05-01 12:32:58] [EMAIL PROTECTED] my simple patch: http://news.php.net/php.internals/15768 [2005-04-05 09:26:03] [EMAIL PROTECTED] See also bug #32580 [2005-03-25 01:19:51] [EMAIL PROTECTED] Andi, this was verified still to happen in HEAD. [2005-01-23 13:57:03] [EMAIL PROTECTED] The problem is that the code isn't staandard. An alias must defined in the same file as the aliased function file. So, in theory, moving that declaration to zend.c (where zend_error() is declared) whould solve the problems. [2005-01-20 19:02:25] maande10 at vt dot edu Found this problem when compiling the php5-200501192330 snapshot on Solaris 8. gcc 3.4.2. Switching to the alternate definition of zend_error_noreturn() in Zend/zend_execute.c fixed the compile problem. The remainder of the comments for this report are too long. To view the rest of the comments, please view the bug report online at http://bugs.php.net/30641 -- Edit this bug report at http://bugs.php.net/?id=30641&edit=1
#32580 [Bgs->Csd]: CVS PHP 5.1.x Compile error on Solaris 9
ID: 32580 Updated by: [EMAIL PROTECTED] Reported By: Oscar dot Castillo at jpl dot nasa dot gov -Status: Bogus +Status: Closed Bug Type: Compile Failure Operating System: solaris 9 PHP Version: 5CVS-2005-04-05 (dev) New Comment: Fixed in CVS HEAD. Previous Comments: [2005-04-05 09:25:24] [EMAIL PROTECTED] Please do not submit the same bug more than once. An existing bug report already describes this very problem. Even if you feel that your issue is somewhat different, the resolution is likely to be the same. Thank you for your interest in PHP. See bug #30641 [2005-04-05 03:34:43] Oscar dot Castillo at jpl dot nasa dot gov Description: I downloaded the latest CVS php5-200504041830 (as suggested in bug #32491) and have failed to compile correctly. The configure options I use are as follows: ./configure --prefix=/usr/local/php --with-nsapi=/usr/ns-home/operational_server This is the compile error I receive: /bin/sh /usr/local/src/php_src/php5-200504041830/libtool --silent --preserve-dup-deps --mode=compile /usr/local/src/php_src/php5-200504041830/meta_ccld -IZend/ -I/usr/local/src/php_src/php5-200504041830/Zend/ -DPHP_ATOM_INC -I/usr/local/src/php_src/php5-200504041830/include -I/usr/local/src/php_src/php5-200504041830/main -I/usr/local/src/php_src/php5-200504041830 -I/usr/ns-home/operational_server/plugins/include -I/usr/local/include/libxml2 -I/usr/local/include -I/usr/local/src/php_src/php5-200504041830/TSRM -I/usr/local/src/php_src/php5-200504041830/Zend -D_POSIX_PTHREAD_SEMANTICS -D_POSIX_PTHREAD_SEMANTICS -D_REENTRANT -g -O2 -pthreads -DZTS -c /usr/local/src/php_src/php5-200504041830/Zend/zend_execute.c -o Zend/zend_execute.lo -O0 /usr/ccs/bin/as: "/tmp/ccA7i1xh.s": error: symbol "zend_error" is used but not defined /usr/ccs/bin/as: "/tmp/ccA7i1xh.s": internal error: evaluate_symbol_expression(): op 20? make: *** [Zend/zend_execute.lo] Error 1 Thanks in advance for your help. Reproduce code: --- ./configure --prefix=/usr/local/php --with-nsapi=/usr/ns-home/operational_server Expected result: Successfull compilation of the latest CVS version of PHP 5 Actual result: -- /bin/sh /usr/local/src/php_src/php5-200504041830/libtool --silent --preserve-dup-deps --mode=compile /usr/local/src/php_src/php5-200504041830/meta_ccld -IZend/ -I/usr/local/src/php_src/php5-200504041830/Zend/ -DPHP_ATOM_INC -I/usr/local/src/php_src/php5-200504041830/include -I/usr/local/src/php_src/php5-200504041830/main -I/usr/local/src/php_src/php5-200504041830 -I/usr/ns-home/operational_server/plugins/include -I/usr/local/include/libxml2 -I/usr/local/include -I/usr/local/src/php_src/php5-200504041830/TSRM -I/usr/local/src/php_src/php5-200504041830/Zend -D_POSIX_PTHREAD_SEMANTICS -D_POSIX_PTHREAD_SEMANTICS -D_REENTRANT -g -O2 -pthreads -DZTS -c /usr/local/src/php_src/php5-200504041830/Zend/zend_execute.c -o Zend/zend_execute.lo -O0 /usr/ccs/bin/as: "/tmp/ccA7i1xh.s": error: symbol "zend_error" is used but not defined /usr/ccs/bin/as: "/tmp/ccA7i1xh.s": internal error: evaluate_symbol_expression(): op 20? make: *** [Zend/zend_execute.lo] Error 1 -- Edit this bug report at http://bugs.php.net/?id=32580&edit=1
#31525 [Asn->Csd]: object reference being dropped. $this getting lost.
ID: 31525
Updated by: [EMAIL PROTECTED]
Reported By: yml at yml dot com
-Status: Assigned
+Status: Closed
Bug Type: Zend Engine 2 problem
Operating System: *
PHP Version: 5CVS-2005-03-03
Assigned To: andi
New Comment:
Fixed in CVS HEAD and PHP_5_0.
Previous Comments:
[2005-04-29 03:46:43] [EMAIL PROTECTED]
Andi, I think you once responded to similar issue regarding return()
with/without parenthesis..
[2005-03-06 05:55:37] yml at yml dot com
Problem found.
Removing all the ()'s from reference returning functions and the
problem has completely disappeared.
However, the case should be caught by the parser and a warning
generated. Using parens around returns returning references will cause
symbol table corruption occassionally ...
[2005-03-06 02:43:51] michaels at crye-leike dot com
True, if getThis() is declared to return a reference then everything
works as expected. However, looking through the original reproduce
code I noticed something else. If you add parentheses around $this in
getThis() then the unexpected behavior returns. Complete code:
getThis();
}
}
$bar = new Foo();
$bar->destroyThis();
var_dump($bar);
?>
Produces:
NULL
Expected:
object(Foo)#1 (0) {
}
[2005-03-06 01:50:27] yml at yml dot com
Unfortunately the shortened script works as it should if you declare
getThis to return a reference as in
function &getThis()
If however, you refer to the "too-long" script I put together at:
http://www.formvista.com/uploaded_files/php5_drops_object.php.txt
There is something different about it that causes $this to get dropped
even when the method is declared return-by-reference.
I haven't been able to narrow it down but it's entirely possible I'm
overlooking something obvious.
It's got to be something related to legacy pass by reference notation
=&. The strange thing is it worked in 5.0.1 and broke in 5.0.2 or .3.
[2005-03-06 01:26:05] michaels at crye-leike dot com
FWIW, here's a shorter script that reproduces the problem for me on PHP
5.0.3:
getThis();
}
}
$bar = new Foo();
$bar->destroyThis();
var_dump($bar);
?>
This outputs:
NULL
If I change the assign-by-reference operator (=&) to the normal
assignment operator (=) inside destroyThis(), I get:
object(Foo)#1 (0) {
}
Hope this helps...
The remainder of the comments for this report are too long. To view
the rest of the comments, please view the bug report online at
http://bugs.php.net/31525
--
Edit this bug report at http://bugs.php.net/?id=31525&edit=1
#29971 [Asn->Csd]: variables_order behaviour
ID: 29971
Updated by: [EMAIL PROTECTED]
Reported By: [EMAIL PROTECTED]
-Status: Assigned
+Status: Closed
Bug Type: *General Issues
Operating System: *
PHP Version: 5CVS-2005-04-03
Assigned To: zeev
New Comment:
Fixed in CVS HEAD and PHP_5_0.
Previous Comments:
[2005-04-05 23:43:08] [EMAIL PROTECTED]
The leak is fixed, but the autoglobals are still populated.
I'm starting to think that it was done intentionally.
[2005-03-07 21:05:33] [EMAIL PROTECTED]
I think this has something to do with the JIT initialization..Zeev, can
you check this please?
[2004-09-04 14:00:11] [EMAIL PROTECTED]
Additionally there are some leaks reported:
/home/dev/php-src/main/php_variables.c(659) : Freeing 0x0827550C (32
bytes), script=-
/home/dev/php-src/Zend/zend_hash.c(169) : Actual location (location was
relayed)
Last leak repeated 1 time
/home/dev/php-src/main/php_variables.c(658) : Freeing 0x0827546C (16
bytes), script=-
This happens only if E or S is absent from variables_order.
[2004-09-03 16:01:21] [EMAIL PROTECTED]
Description:
Hi,
regardless of the setting for variables_order, all types of variables
(EGPCS) are registered by php. This is true for the apache, cli and cgi
SAPI.
For sure I doublechecked using the right ini-file.
If this is desired behaviour at least the docs are confusing:
http://www.php.net/manual/en/ini.sect.data-handling.php#ini.variables-order
as they imply, that variables which are not set in variables_order are
ignored by php.
Reproduce code:
---
Short repro-skript for cli:
./php -n -d variables_order="GPC" -r 'var_dump($_ENV,
$_SERVER);var_dump(ini_get("variables_order"));'
./php -v:
PHP 5.0.1 (cli) (built: Aug 31 2004 00:23:09)
Copyright (c) 1997-2004 The PHP Group
Zend Engine v2.0.1, Copyright (c) 1998-2004 Zend Technologies
Expected result:
array(0) {
}
array(0) {
}
string(3) "GPC"
Actual result:
--
$_ENV and $_SERVER are filled
--
Edit this bug report at http://bugs.php.net/?id=29971&edit=1
#33116 [Asn->Csd]: crash when assigning class name to global variable in __autoload
ID: 33116 Updated by: [EMAIL PROTECTED] Reported By: segv74 at gmail dot com -Status: Assigned +Status: Closed Bug Type: Reproducible crash Operating System: linux 2.4.28 PHP Version: 5.0.3 Assigned To: dmitry New Comment: Fixed in CVS HEAD and PHP_5_0. Previous Comments: [2005-05-26 03:29:10] segv74 at gmail dot com patch below seems works fine. $ diff Zend/zend_execute_API.c zend_execute_API.c 911c911 < zval class_name, *class_name_ptr = &class_name; --- > zval *class_name_ptr; 950,951c950,951 < INIT_PZVAL(class_name_ptr); < ZVAL_STRINGL(class_name_ptr, name, name_length, 0); --- > MAKE_STD_ZVAL(class_name_ptr); > ZVAL_STRINGL(class_name_ptr, name, name_length, 1); [2005-05-24 10:02:22] [EMAIL PROTECTED] Please try using this CVS snapshot: http://snaps.php.net/php5-latest.tar.gz For Windows: http://snaps.php.net/win32/php5-win32-latest.zip This one has some other (propably) related bugs fixed. So please try it out too. [2005-05-24 09:59:36] segv74 at gmail dot com last backtrace data of gdb was slightly diffrent examples. ( using static member variables instead of $GLOBALS ) but, both two source cause segment fault and produce wrong output on php snapshot. [2005-05-24 09:56:04] segv74 at gmail dot com php5-STABLE-latest.tar.gz shows same buggy results too. (gdb) bt #0 0x08170036 in _efree (ptr=0xbfffd040) at /home/ssw/work/php5-STABLE-200505240632/Zend/zend_alloc.c:281 #1 0x08189ae8 in zend_hash_destroy (ht=0x827ca24) at /home/ssw/work/php5-STABLE-200505240632/Zend/zend_hash.c:519 #2 0x081821d7 in _zval_dtor (zvalue=0x827ca8c) at /home/ssw/work/php5-STABLE-200505240632/Zend/zend_variables.c:52 #3 0x08179b48 in _zval_ptr_dtor (zval_ptr=0x827cab8) at /home/ssw/work/php5-STABLE-200505240632/Zend/zend_execute_API.c:400 #4 0x08189bb8 in zend_hash_clean (ht=0x827c89c) at /home/ssw/work/php5-STABLE-200505240632/Zend/zend_hash.c:545 #5 0x0817c79e in zend_cleanup_class_data (pce=0x827e08c) at /home/ssw/work/php5-STABLE-200505240632/Zend/zend_opcode.c:139 #6 0x08189dd8 in zend_hash_apply (ht=0x81ffdb0, apply_func=0x817c770 ) at /home/ssw/work/php5-STABLE-200505240632/Zend/zend_hash.c:664 #7 0x0817988c in shutdown_executor () at /home/ssw/work/php5-STABLE-200505240632/Zend/zend_execute_API.c:257 #8 0x081834c5 in zend_deactivate () at /home/ssw/work/php5-STABLE-200505240632/Zend/zend.c:824 #9 0x0814d326 in php_request_shutdown (dummy=0x0) at /home/ssw/work/php5-STABLE-200505240632/main/main.c:1224 #10 0x081ad55c in main (argc=2, argv=0xb654) at /home/ssw/work/php5-STABLE-200505240632/sapi/cgi/cgi_main.c:1640 (gdb) up ... #4 0x08189bb8 in zend_hash_clean (ht=0x827c89c) at /home/ssw/work/php5-STABLE-200505240632/Zend/zend_hash.c:545 545 ht->pDestructor(q->pData); (gdb) print (char *)&*q.arKey $6 = 0x827cacc "included_classes" [2005-05-24 09:27:30] [EMAIL PROTECTED] Please try using this CVS snapshot: http://snaps.php.net/php5-STABLE-latest.tar.gz For Windows: http://snaps.php.net/win32/php5.0-win32-latest.zip The remainder of the comments for this report are too long. To view the rest of the comments, please view the bug report online at http://bugs.php.net/33116 -- Edit this bug report at http://bugs.php.net/?id=33116&edit=1
#28476 [Ver->Bgs]: string to array variable transformation
ID: 28476
Updated by: [EMAIL PROTECTED]
Reported By: nepto at platon dot sk
-Status: Verified
+Status: Bogus
Bug Type: Arrays related
Operating System: *
PHP Version: 5CVS, 4CVS (2005-02-03)
New Comment:
This is not a bug. Look careful that do you do.
All work as expected.
Previous Comments:
[2004-05-21 21:00:44] [EMAIL PROTECTED]
Implicit array creation ONLY occurs if the target variable is either
(A) not set, or (B) empty. In this case the target variable is already
set to a non-blank string so it qualifies neither of those criteria.
It seems to me like this should throw a notice since, as you state, the
results are very much unexpected.
===
RCS file: /repository/Zend/Attic/zend_execute.c,v
retrieving revision 1.316.2.34
diff -u -r1.316.2.34 zend_execute.c
--- Zend/zend_execute.c 1 Apr 2004 22:05:38 - 1.316.2.34
+++ Zend/zend_execute.c 21 May 2004 18:59:27 -
@@ -780,6 +780,9 @@
array_init(container);
break;
}
+ } else if ((container->type == IS_STRING || container->type ==
IS_BOOL) &&
+ (type == BP_VAR_RW || type ==
BP_VAR_W)) {
+ zend_error(E_NOTICE, "Implicit array creation failed:
Target variable contains non-empty string or boolean true value.");
}
switch (container->type) {
While this is considered, I'd suggest explicitly initializing your
arrays before pushing data onto them.
[2004-05-21 20:10:16] nepto at platon dot sk
Description:
Transformation of string variable to array variable does not work as
expected when prticular assignment is used.
It can be also bug in the var_dump(), but I do not suppose this.
Reproduce code:
---
* Copyright (c) 2004 Platon SDG, http://platon.sk/
* Licensed under terms of GNU General Public License.
* All rights reserved.
*
* Changelog:
* 2004-05-10 - created
*
*/
/* $Platon$ */
$str = 'string';
$ar['key'] = $str;
var_dump($ar['key']); // string(6) "string"
$ar['key']['sub-key'] = $ar['key'];
var_dump($ar['key']); /* string(6) "string"
but expected is:
array(1) {
["sub-key"]=>
string(6) "string"
}
*/
$ar['key'] = array('sub-key' => $ar['key']);
var_dump($ar['key']); /* now OK:
array(1) {
["sub-key"]=>
string(6) "string"
}
*/
/* Modeline for ViM {{{
* vim: set ts=4:
* vim600: fdm=marker fdl=0 fdc=0:
* }}} */
?>
Expected result:
Written in the code.
Actual result:
--
Written in the code as well.
--
Edit this bug report at http://bugs.php.net/?id=28476&edit=1
#32941 [Asn]: Sending structured exception kills a php
ID: 32941 Updated by: [EMAIL PROTECTED] Reported By: steckovic at aarongroup dot cz Status: Assigned Bug Type: SOAP related Operating System: FEDORA PHP Version: 5.0.4 Assigned To: dmitry New Comment: I cannot access WSDL file 'http://212.24.157.117:8080/axis/services/echo?wsdl' and cannot reprodoce and fix bug without it. Previous Comments: [2005-05-05 15:48:37] steckovic at aarongroup dot cz I can't found any excute statememt (I try 2000 calls back) Core dump has 33MB Do you want to send it to you? #0 0x0816a248 in attr_is_equal_ex (node=0x8457540, name=0x831bf18 "href", ns=0x0) at /home/src/php/php5-200505030430/ext/soap/php_xml.c:212 #1 0x0816a363 in get_attribute_ex (node=0x8457540, name=0x831bf18 "href", ns=0x0) at /home/src/php/php5-200505030430/ext/soap/php_xml.c:246 #2 0x08141d99 in check_and_resolve_href (data=0x8457500) at /home/src/php/php5-200505030430/ext/soap/php_encoding.c:2753 #3 0x081408fe in guess_zval_convert (type=0x8455b1c, data=0x8457500) at /home/src/php/php5-200505030430/ext/soap/php_encoding.c:2289 #4 0x08141abc in sdl_guess_convert_zval (enc=0x8455b1c, data=0x8457500) at /home/src/php/php5-200505030430/ext/soap/php_encoding.c:2616 #5 0x08138fb5 in master_to_zval_int (encode=0x8455b1c, data=0x8457500) at /home/src/php/php5-200505030430/ext/soap/php_encoding.c:327 #6 0x08140ad6 in guess_zval_convert (type=0x8455b1c, data=0x8457500) at /home/src/php/php5-200505030430/ext/soap/php_encoding.c:2337 #7 0x08141abc in sdl_guess_convert_zval (enc=0x8455b1c, data=0x8457500) at /home/src/php/php5-200505030430/ext/soap/php_encoding.c:2616 #8 0x08138fb5 in master_to_zval_int (encode=0x8455b1c, data=0x8457500) at /home/src/php/php5-200505030430/ext/soap/php_encoding.c:327 #9 0x08140ad6 in guess_zval_convert (type=0x8455b1c, data=0x8457500) at /home/src/php/php5-200505030430/ext/soap/php_encoding.c:2337 #10 0x08141abc in sdl_guess_convert_zval (enc=0x8455b1c, data=0x8457500) at /home/src/php/php5-200505030430/ext/soap/php_encoding.c:2616 #11 0x08138fb5 in master_to_zval_int (encode=0x8455b1c, data=0x8457500) at /home/src/php/php5-200505030430/ext/soap/php_encoding.c:327 #12 0x08140ad6 in guess_zval_convert (type=0x8455b1c, data=0x8457500) at /home/src/php/php5-200505030430/ext/soap/php_encoding.c:2337 #13 0x08141abc in sdl_guess_convert_zval (enc=0x8455b1c, data=0x8457500) at /home/src/php/php5-200505030430/ext/soap/php_encoding.c:2616 #14 0x08138fb5 in master_to_zval_int (encode=0x8455b1c, data=0x8457500) at /home/src/php/php5-200505030430/ext/soap/php_encoding.c:327 #15 0x08140ad6 in guess_zval_convert (type=0x8455b1c, data=0x8457500) at /home/src/php/php5-200505030430/ext/soap/php_encoding.c:2337 #16 0x08141abc in sdl_guess_convert_zval (enc=0x8455b1c, data=0x8457500) at /home/src/php/php5-200505030430/ext/soap/php_encoding.c:2616 #17 0x08138fb5 in master_to_zval_int (encode=0x8455b1c, data=0x8457500) at /home/src/php/php5-200505030430/ext/soap/php_encoding.c:327 #18 0x08140ad6 in guess_zval_convert (type=0x8455b1c, data=0x8457500) at /home/src/php/php5-200505030430/ext/soap/php_encoding.c:2337 #19 0x08141abc in sdl_guess_convert_zval (enc=0x8455b1c, data=0x8457500) at /home/src/php/php5-200505030430/ext/soap/php_encoding.c:2616 #20 0x08138fb5 in master_to_zval_int (encode=0x8455b1c, data=0x8457500) at /home/src/php/php5-200505030430/ext/soap/php_encoding.c:327 #21 0x08140ad6 in guess_zval_convert (type=0x8455b1c, data=0x8457500) at /home/src/php/php5-200505030430/ext/soap/php_encoding.c:2337 #22 0x08141abc in sdl_guess_convert_zval (enc=0x8455b1c, data=0x8457500) at /home/src/php/php5-200505030430/ext/soap/php_encoding.c:2616 #23 0x08138fb5 in master_to_zval_int (encode=0x8455b1c, data=0x8457500) at /home/src/php/php5-200505030430/ext/soap/php_encoding.c:327 #24 0x08140ad6 in guess_zval_convert (type=0x8455b1c, data=0x8457500) at /home/src/php/php5-200505030430/ext/soap/php_encoding.c:2337 #25 0x08141abc in sdl_guess_convert_zval (enc=0x8455b1c, data=0x8457500) at /home/src/php/php5-200505030430/ext/soap/php_encoding.c:2616 #26 0x08138fb5 in master_to_zval_int (encode=0x8455b1c, data=0x8457500) at /home/src/php/php5-200505030430/ext/soap/php_encoding.c:327 #27 0x08140ad6 in guess_zval_convert (type=0x8455b1c, data=0x8457500) at /home/src/php/php5-200505030430/ext/soap/php_encoding.c:2337 #28 0x08141abc in sdl_guess_convert_zval (enc=0x8455b1c, data=0x8457500) at /home/src/php/php5-200505030430/ext/soap/php_encoding.c:2616 #29 0x08138fb5 in master_to_zval_int (encode=0x8455b1c, data=0x8457500) at /home/src/php/php5-200505030430/ext/soap/php_encoding.c:327 #30 0x08140ad6 in guess_zval_convert (type=0x8455b1c, data=0x8457500) at /home/src/php/php5-200505030430/ext/soap/php_encoding.c:2337 #31 0x08141abc in sdl_guess_convert_zval (enc=0x8455b1c, data=0x8457500) at /home/src/php/php5-2005050304
#30791 [Ver->Csd]: magic methods (__sleep/__wakeup/__toString) call __call if object is overloaded.
ID: 30791 Updated by: [EMAIL PROTECTED] Reported By: alan at akbkhome dot com -Status: Verified +Status: Closed Bug Type: Zend Engine 2 problem Operating System: * PHP Version: 5CVS-2004-11-15 (dev) Assigned To: dmitry New Comment: Fixed in CVS HEAD and PHP_5_0. Previous Comments: [2005-04-14 09:47:31] [EMAIL PROTECTED] changing title to reflect issue... [2005-04-14 09:42:17] [EMAIL PROTECTED] This bug needs either fixing or verifying as wont-fix. (or documenting) so leaving it as verified until one of those occur... [2005-03-15 01:00:34] 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". [2005-03-07 21:55:43] [EMAIL PROTECTED] This is what I get with latest CVS HEAD: # php5 t.php Notice: serialize(): __sleep should return an array only containing the names of instance-variables to serialize. in /home/jani/t.php on line 10 [2005-01-13 02:13:41] [EMAIL PROTECTED] Changing to verified - although it's not critical (as overload was experimental in 4.x) it is a BC break - and is a relatively unexpected behaviour.. The remainder of the comments for this report are too long. To view the rest of the comments, please view the bug report online at http://bugs.php.net/30791 -- Edit this bug report at http://bugs.php.net/?id=30791&edit=1
#32941 [Asn->Csd]: Sending structured exception kills a php
ID: 32941 Updated by: [EMAIL PROTECTED] Reported By: steckovic at aarongroup dot cz -Status: Assigned +Status: Closed Bug Type: SOAP related Operating System: FEDORA PHP Version: 5.0.4 Assigned To: dmitry New Comment: Fixed in CVS HEAD and PHP_5_0. Previous Comments: [2005-06-01 07:15:20] steckovic at aarongroup dot cz Test server is behind a firewall. I haven't rights to allow access to this server. I can send to you complete implementation of webservice which kills the PHP. Thank you Petr Steckovic [2005-05-27 12:46:08] [EMAIL PROTECTED] I cannot access WSDL file 'http://212.24.157.117:8080/axis/services/echo?wsdl' and cannot reprodoce and fix bug without it. [2005-05-05 15:48:37] steckovic at aarongroup dot cz I can't found any excute statememt (I try 2000 calls back) Core dump has 33MB Do you want to send it to you? #0 0x0816a248 in attr_is_equal_ex (node=0x8457540, name=0x831bf18 "href", ns=0x0) at /home/src/php/php5-200505030430/ext/soap/php_xml.c:212 #1 0x0816a363 in get_attribute_ex (node=0x8457540, name=0x831bf18 "href", ns=0x0) at /home/src/php/php5-200505030430/ext/soap/php_xml.c:246 #2 0x08141d99 in check_and_resolve_href (data=0x8457500) at /home/src/php/php5-200505030430/ext/soap/php_encoding.c:2753 #3 0x081408fe in guess_zval_convert (type=0x8455b1c, data=0x8457500) at /home/src/php/php5-200505030430/ext/soap/php_encoding.c:2289 #4 0x08141abc in sdl_guess_convert_zval (enc=0x8455b1c, data=0x8457500) at /home/src/php/php5-200505030430/ext/soap/php_encoding.c:2616 #5 0x08138fb5 in master_to_zval_int (encode=0x8455b1c, data=0x8457500) at /home/src/php/php5-200505030430/ext/soap/php_encoding.c:327 #6 0x08140ad6 in guess_zval_convert (type=0x8455b1c, data=0x8457500) at /home/src/php/php5-200505030430/ext/soap/php_encoding.c:2337 #7 0x08141abc in sdl_guess_convert_zval (enc=0x8455b1c, data=0x8457500) at /home/src/php/php5-200505030430/ext/soap/php_encoding.c:2616 #8 0x08138fb5 in master_to_zval_int (encode=0x8455b1c, data=0x8457500) at /home/src/php/php5-200505030430/ext/soap/php_encoding.c:327 #9 0x08140ad6 in guess_zval_convert (type=0x8455b1c, data=0x8457500) at /home/src/php/php5-200505030430/ext/soap/php_encoding.c:2337 #10 0x08141abc in sdl_guess_convert_zval (enc=0x8455b1c, data=0x8457500) at /home/src/php/php5-200505030430/ext/soap/php_encoding.c:2616 #11 0x08138fb5 in master_to_zval_int (encode=0x8455b1c, data=0x8457500) at /home/src/php/php5-200505030430/ext/soap/php_encoding.c:327 #12 0x08140ad6 in guess_zval_convert (type=0x8455b1c, data=0x8457500) at /home/src/php/php5-200505030430/ext/soap/php_encoding.c:2337 #13 0x08141abc in sdl_guess_convert_zval (enc=0x8455b1c, data=0x8457500) at /home/src/php/php5-200505030430/ext/soap/php_encoding.c:2616 #14 0x08138fb5 in master_to_zval_int (encode=0x8455b1c, data=0x8457500) at /home/src/php/php5-200505030430/ext/soap/php_encoding.c:327 #15 0x08140ad6 in guess_zval_convert (type=0x8455b1c, data=0x8457500) at /home/src/php/php5-200505030430/ext/soap/php_encoding.c:2337 #16 0x08141abc in sdl_guess_convert_zval (enc=0x8455b1c, data=0x8457500) at /home/src/php/php5-200505030430/ext/soap/php_encoding.c:2616 #17 0x08138fb5 in master_to_zval_int (encode=0x8455b1c, data=0x8457500) at /home/src/php/php5-200505030430/ext/soap/php_encoding.c:327 #18 0x08140ad6 in guess_zval_convert (type=0x8455b1c, data=0x8457500) at /home/src/php/php5-200505030430/ext/soap/php_encoding.c:2337 #19 0x08141abc in sdl_guess_convert_zval (enc=0x8455b1c, data=0x8457500) at /home/src/php/php5-200505030430/ext/soap/php_encoding.c:2616 #20 0x08138fb5 in master_to_zval_int (encode=0x8455b1c, data=0x8457500) at /home/src/php/php5-200505030430/ext/soap/php_encoding.c:327 #21 0x08140ad6 in guess_zval_convert (type=0x8455b1c, data=0x8457500) at /home/src/php/php5-200505030430/ext/soap/php_encoding.c:2337 #22 0x08141abc in sdl_guess_convert_zval (enc=0x8455b1c, data=0x8457500) at /home/src/php/php5-200505030430/ext/soap/php_encoding.c:2616 #23 0x08138fb5 in master_to_zval_int (encode=0x8455b1c, data=0x8457500) at /home/src/php/php5-200505030430/ext/soap/php_encoding.c:327 #24 0x08140ad6 in guess_zval_convert (type=0x8455b1c, data=0x8457500) at /home/src/php/php5-200505030430/ext/soap/php_encoding.c:2337 #25 0x08141abc in sdl_guess_convert_zval (enc=0x8455b1c, data=0x8457500) at /home/src/php/php5-200505030430/ext/soap/php_encoding.c:2616 #26 0x08138fb5 in master_to_zval_int (encode=0x8455b1c, data=0x8457500) at /home/src/php/php5-200505030430/ext/soap/php_encoding.c:327 #27 0x08140ad6 in guess_zval_convert (type=0x8455b1c, data=0x8457500) at /home/src/php/php5-200505030430/ext/soap/php_encoding.c:2337 #28 0x08141abc in sdl
#27598 [Ver->Csd]: list() array key assignment causes HUGE memory leak
ID: 27598
Updated by: [EMAIL PROTECTED]
Reported By: lf at burntmail dot com
-Status: Verified
+Status: Closed
Bug Type: Zend Engine 2 problem
Operating System: *
PHP Version: 5CVS-2005-04-30
New Comment:
Fixed in CVS HEAD and PHP_5_0
Previous Comments:
[2004-03-15 08:54:58] [EMAIL PROTECTED]
Does not leak at all with PHP_4_3 branch.
[2004-03-14 17:48:20] lf at burntmail dot com
Description:
When using array keys as variables in the list() function there is a
noticiable memory leak.
It doesn't seem to matter if you assign values to the array key's
before using them in the array.
Reproduce code:
---
//memory leak!
while (1)
{
$out = array();
$arr = array('a','b','c');
list($out['a'], $out['b'], $out['c']) = $arr;
}
//NO memory leak!!
while (1)
{
$out = array();
$a = &$out['a'];
$b = &$out['b'];
$c = &$out['c'];
$arr = array('a','b','c');
list($a, $b, $c) = $arr;
}
Expected result:
Output every 4000 loops
# | Memory usage
4000 | 68 KB
8000 | 68 KB
12000 | 68 KB
16000 | 68 KB
2 | 68 KB
24000 | 68 KB
28000 | 68 KB
32000 | 68 KB
36000 | 68 KB
4 | 68 KB
44000 | 68 KB
48000 | 68 KB
52000 | 68 KB
56000 | 68 KB
6 | 68 KB
64000 | 68 KB
68000 | 68 KB
72000 | 68 KB
76000 | 68 KB
8 | 68 KB
84000 | 68 KB
88000 | 68 KB
92000 | 68 KB
96000 | 68 KB
10 | 68 KB
104000 | 68 KB
108000 | 68 KB
112000 | 68 KB
Actual result:
--
Output every 4000 loops
# | Memory usage
4000 | 349 KB
8000 | 630 KB
12000 | 911 KB
16000 | 1.2 MB
2 | 1.4 MB
24000 | 1.7 MB
28000 | 2.0 MB
32000 | 2.3 MB
36000 | 2.5 MB
4 | 2.8 MB
44000 | 3.1 MB
48000 | 3.4 MB
52000 | 3.6 MB
56000 | 3.9 MB
6 | 4.2 MB
64000 | 4.5 MB
68000 | 4.7 MB
72000 | 5.0 MB
76000 | 5.3 MB
8 | 5.6 MB
84000 | 5.8 MB
88000 | 6.1 MB
92000 | 6.4 MB
96000 | 6.7 MB
10 | 6.9 MB
104000 | 7.2 MB
108000 | 7.5 MB
112000 | 7.8 MB
--
Edit this bug report at http://bugs.php.net/?id=27598&edit=1
#30080 [Ver->Csd]: Passing array or non array of objects
ID: 30080
Updated by: [EMAIL PROTECTED]
Reported By: portfolio at gmx dot co dot uk
-Status: Verified
+Status: Closed
Bug Type: Zend Engine 2 problem
Operating System: *
PHP Version: 5CVS-2005-03-09
New Comment:
Fixed in CVS HEAD and PHP_5_0.
Previous Comments:
[2005-03-09 21:53:46] [EMAIL PROTECTED]
# sapi/cli/php /home/jani/t.php
UNKNOWN:0
/usr/src/php/php5/Zend/zend_vm_execute.h(370) : Freeing 0x092FE03C (16
bytes), script=/home/jani/t.php
=== Total 1 memory leaks detected ===
[2005-01-13 19:00:06] [EMAIL PROTECTED]
No crash here, but I still got "UNKNOWN:0" as var_dump's output.
[2004-11-28 16:35:55] [EMAIL PROTECTED]
Reproducible only with HEAD & 5.0.x.
[2004-09-14 17:55:33] php30080 at pointbeing dot net
Behaviour is reproducible using 5.00 on Fedora Linux (core 2).
There's an ongoing discussion of the behaviour on the Sitepoint forums
here:
http://www.sitepoint.com/forums/showthread.php?t=195284
By way of a summary, it appears that the problems occur when
constructing a number of new objects without assigning them anywhere,
so:
new A( array( new B(), new C())); // fails
$a = new A( array( new B(), new C())); // fine
some_function( array( new B(), new C())); //fine
[2004-09-14 05:44:10] portfolio at gmx dot co dot uk
Description:
When I pass an array of objects without first initializing them with a
variable, I get either a crash or error (Depends on whether if its
array).
Reproduce code:
---
class A {
function A($arrayobj) {
while(list($key, $value) = each($arrayobj)) {
echo $value->spit();
}
}
}
class B {
function spit() {
return 'This is class B' . "\n";
}
}
class C {
function spit() {
return 'This is class C' . "\n";
}
}
new A( array( new B(), new C()));
Expected result:
I got this error:
This is class B
Fatal error: Call to a member function spit() on a non-object in
If I do:
$b = new B; $c = new C;
new A( array($b, $c));
It works but very long winded.
Another bug here causes Apache to crash:
class A
{
function A($value) {
echo $value->spit();
}
}
class B {
function spit() {
return 'This is class B' . "\n";
}
}
new A( new B());
--
Edit this bug report at http://bugs.php.net/?id=30080&edit=1
#30394 [Ver->Csd]: Assignment operators yield wrong result with __get/__set
ID: 30394
Updated by: [EMAIL PROTECTED]
Reported By: php at hartwerk dot com
-Status: Verified
+Status: Closed
Bug Type: Zend Engine 2 problem
Operating System: Linux
PHP Version: 5CVS-STABLE-03-23
New Comment:
Fixed in PHP_5_0.
This bug was already fixed in HEAD long time ago with new garbage
collector.
Previous Comments:
[2005-03-23 22:51:34] [EMAIL PROTECTED]
With clean 5.0.x-CVS I get:
2
Fatal error: Unsupported operand types in index.php on line 23
with the code below.
HEAD works just fine.
[2004-11-04 16:10:03] [EMAIL PROTECTED]
It's 5.0.x specific bug.
[2004-10-15 18:46:51] php at hartwerk dot com
An easier work-around would be $c->a = $c->a + max( 0, 1 ), but
work-arounds do not solve bugs..
[2004-10-15 12:13:47] ante dot dfg at moj dot net
This code works if you return the value from _get via reference
try:
public function &__get( $what ) {
return $this->_p[ $what ];
}
[2004-10-11 11:24:19] php at hartwerk dot com
Description:
When there is a function on the right-hand side of an assignment
operator expression, and the variable is to be accessed via
__get/__set, the operation yields wrong results.
Reproduce code:
---
class Container
{
public function __get( $what )
{
return $this->_p[ $what ];
}
public function __set( $what, $value )
{
$this->_p[ $what ] = $value;
}
private $_p = array();
}
$c = new Container();
$c->a = 1;
$c->a += 1;
print $c->a;// --> 2
print " - ";
$c->a += max( 0, 1 );
print $c->a;// --> 4 (!)
Expected result:
2 - 3
Actual result:
--
2 - 4
--
Edit this bug report at http://bugs.php.net/?id=30394&edit=1
#31300 [Opn->Csd]: ArrayAccess and __get crash when using string concat in key
ID: 31300 Updated by: [EMAIL PROTECTED] Reported By: gardan at gmx dot com -Status: Open +Status: Closed Bug Type: Zend Engine 2 problem Operating System: Win32 PHP Version: 5.0.5-dev (26 May 05) New Comment: This bug is fixed in CVS HEAD nad PHP_5_0. See Zend/tests/object_handlers.phpt Previous Comments: [2005-05-27 00:51:05] [EMAIL PROTECTED] I am able to replicate this using the latest build: PHP Version 5.0.5-dev Build Date May 26 2005 18:16:00 The code provided "[26 Dec 2004 7:32am CET] Beater at orgalan dot de" causes Apache to crash with error: [Thu May 26 23:38:27 2005] [notice] Parent: child process exited with status 3221225477 -- Restarting. [Thu May 26 23:38:27 2005] [notice] Apache/2.0.54 (Win32) PHP/5.0.5-dev configured -- resuming normal operations [2005-05-07 01:00:04] 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". [2005-04-29 15:59:07] [EMAIL PROTECTED] Please try using this CVS snapshot: http://snaps.php.net/php5-STABLE-latest.tar.gz For Windows: http://snaps.php.net/win32/php5.0-win32-latest.zip Can't reproduce with latest HEAD & 5.0. [2005-03-05 03:55:23] matt dot bevan at marginsoftware dot com Consider this bug confirmed using Apache/2.0.52 (Gentoo/Linux) PHP/5.0.3 but is not re-producible in a small amount of code. In my case, performing strange acts got around the bug when using the array access more than once with three other variable assignments in-between the first call and second: - The first dot-concatenated call worked fine. - The second segfaulted Apache, unless: - The first call is commented out, or - The second call is placed right below the first, or - One line of three lines is commented out. - All array accesses are changed to use sprintf not dot concatenation. It doesn't matter which line of the three simple, static variable assignments is commented. This bug drove me crazy all today. I'm going to have nightmares about this bug. ;) [2005-01-11 08:24:01] [EMAIL PROTECTED] ArrayAccess is defined and controlled by the engine not SPL The remainder of the comments for this report are too long. To view the rest of the comments, please view the bug report online at http://bugs.php.net/31300 -- Edit this bug report at http://bugs.php.net/?id=31300&edit=1
#31086 [Ver->Csd]: Type hinting in constructor crashes php
ID: 31086
Updated by: [EMAIL PROTECTED]
Reported By: junkmail at konvergencia dot hu
-Status: Verified
+Status: Closed
Bug Type: Zend Engine 2 problem
Operating System: *
PHP Version: 5CVS-2005-02-14
New Comment:
This is the same as #30080, that is already fixed in CVS HEAD and
PHP_5_0.
Previous Comments:
[2005-01-23 21:09:14] [EMAIL PROTECTED]
Funny, while the first works:
php -r 'class A{} class B { function __construct(A $x){}} $b=new B(new
A);'
the second does not:
php -r 'class A{} class B { function __construct(A $x){}} new B(new
A);'
Fatal error: Argument 1 must be an object of class A in Command line
code on line 1
[2005-01-23 20:36:52] [EMAIL PROTECTED]
On the other hand this script fully works.
Therefore I think some wrong assumption is made for the temporary
variable received in the handler specific to constructors.
[2005-01-23 20:32:15] [EMAIL PROTECTED]
Confirmed both on Linux and OSX.
It seems presence of a type hint doesn't matter.
#0 zend_std_object_get_class (object=0x)
at /home/moriyoshi/src/php-src-5/Zend/zend_object_handlers.c:825
#1 0x0823a597 in zend_get_class_entry (zobject=0x8557dd4)
at /home/moriyoshi/src/php-src-5/Zend/zend_API.c:227
#2 0x082bbde0 in zend_verify_arg_type (zf=0x, arg_num=1,
arg=0x8556e94) at
/home/moriyoshi/src/php-src-5/Zend/zend_execute.c:614
#3 0x0825c75a in ZEND_RECV_SPEC_HANDLER (execute_data=0xbfffd190)
at zend_vm_execute.h:343
#4 0x0825bbe8 in execute (op_array=0x8568984) at zend_vm_execute.h:78
#5 0x0825c179 in zend_do_fcall_common_helper_SPEC
(execute_data=0xbfffd320)
at zend_vm_execute.h:204
#6 0x0825bbe8 in execute (op_array=0x8561c04) at zend_vm_execute.h:78
#7 0x08239e1f in zend_execute_scripts (type=8, retval=0x0,
file_count=3)
at /home/moriyoshi/src/php-src-5/Zend/zend.c:1058
#8 0x081fd08f in php_execute_script (primary_file=0xb720)
at /home/moriyoshi/src/php-src-5/main/main.c:1636
#9 0x082be3ae in main (argc=2, argv=0xb7e4)
[2005-01-21 16:23:11] junkmail at konvergencia dot hu
I can reproduce the error with the latest -STABLE snapshot
(php5-STABLE-200501211330).
php -v output:
PHP 5.0.4-dev (cgi) (built: Jan 21 2005 15:44:03)
Copyright (c) 1997-2004 The PHP Group
Zend Engine v2.0.4-dev, Copyright (c) 1998-2004 Zend Technologies
The backtrace is the same.
I've tried to compile with different optimization levels (from none to
-O2, with and without -fno-strict-aliasing) and with gcc 2.95 (the
default compiler on FreeBSD 4.x, and gcc 3.3) The result is always the
same :/
[2005-01-11 23:40:17] [EMAIL PROTECTED]
Please try using this CVS snapshot:
http://snaps.php.net/php5-STABLE-latest.tar.gz
For Windows:
http://snaps.php.net/win32/php5.0-win32-latest.zip
I can't reproduce it with latest 5.0.x-CVS version.
The remainder of the comments for this report are too long. To view
the rest of the comments, please view the bug report online at
http://bugs.php.net/31086
--
Edit this bug report at http://bugs.php.net/?id=31086&edit=1
#32334 [Ver->Csd]: __set acts unexpected with variable variables
ID: 32334
Updated by: [EMAIL PROTECTED]
Reported By: mk at peytz dot dk
-Status: Verified
+Status: Closed
Bug Type: Zend Engine 2 problem
Operating System: *
PHP Version: 5CVS-2005-04-04
New Comment:
This bug is already fixed in CVS HEAD and PHP_5_0.
See Zend/tests/object_handlers.phpt
Previous Comments:
[2005-04-04 00:00:56] [EMAIL PROTECTED]
Changed the var_export() -> var_dump() and got this with
latest CVS:
object(Setter)#1 (2) {
["_fields:private"]=>
array(2) {
["a"]=>
int(1)
["b"]=>
int(2)
}
["_changedFields:private"]=>
array(2) {
[0]=>
string(1) "a"
[1]=>
&UNKNOWN:0
}
}
[2005-04-01 13:51:43] mk at peytz dot dk
Still present in 5.0.4 but now only with NULL values.
[2005-03-19 12:38:36] [EMAIL PROTECTED]
Can't reproduce *your* behaviour with latest 5.0.x & 5.1 CVS.
But some issue really exists, as I get NULL instead of 'b' with both
branches.
[2005-03-16 13:29:45] mk at peytz dot dk
Description:
When setting variable variable values on a instance of a class with an
overloading __set function changing another instance variable goes
wrong.
(I'm reporting it for version 5.0.3 because the current cvs snapshot
would not compile.)
Reproduce code:
---
http://dev.peytz.dk/~mk/setter.php
_fields[$name] = $value;
// add to list of changed fields
$this->_changedFields[] = $name;
}
}
$foo = new Setter;
$foo->a = 1;
$var = "b";
$foo->$var = 2;
var_export($foo);
?>
Expected result:
class Setter {
private $_fields =
array (
'a' => 1,
'b' => 2,
);
private $_changedFields =
array (
0 => 'a',
1 => 'b',
);
}
Actual result:
--
class Setter {
private $_fields =
array (
'a' => 1,
'b' => 2,
);
private $_changedFields =
array (
0 => 'a',
1 => ' ',
);
}
--
Edit this bug report at http://bugs.php.net/?id=32334&edit=1
#32437 [Ver->Csd]: two leaks in zend_execute.c when executing bug22836.phpt
ID: 32437 Updated by: [EMAIL PROTECTED] Reported By: tony2001 at phpclub dot net -Status: Verified +Status: Closed Bug Type: Zend Engine 2 problem Operating System: SuSE 9.2 PHP Version: 5.* New Comment: This bug is already fixed together with #22836 in CVS HEAD and PHP_5_0. Previous Comments: [2005-04-08 14:54:30] [EMAIL PROTECTED] Patch is available, but not yet committed as there are a couple of more problems. [2005-04-03 23:53:06] [EMAIL PROTECTED] Leaks still present in PHP_5_0 (and output not anywhere close what it should be ) In HEAD, the output is again different and test fails but no leaks.. [2005-03-23 23:13:28] tony2001 at phpclub dot net Description: Found 2 leaks in zend_execute.c when executing Zend/tests/bug22836.phpt. /usr/src/dev/php-src_5_0_clean/Zend/zend_execute.c(616) : Freeing 0x1BF0F544 (4 bytes), script=/www/index.php /usr/src/dev/php-src_5_0_clean/Zend/zend_variables.c(137) : Actual location (location was relayed) /usr/src/dev/php-src_5_0_clean/Zend/zend_execute.c(271) : Freeing 0x1BF0FBB4 (16 bytes), script=/www/index.php Reproduce code: --- The same as in bug #22836. Pasting it here for additional convenience. -- Edit this bug report at http://bugs.php.net/?id=32437&edit=1
#33171 [Ver->Csd]: foreach enumerates private fields declared in base classes
ID: 33171
Updated by: [EMAIL PROTECTED]
Reported By: ladislav dot prosek at matfyz dot cz
-Status: Verified
+Status: Closed
Bug Type: Zend Engine 2 problem
Operating System: Win XP Pro SP2
PHP Version: 5.0.4
New Comment:
Fixed in CVS HEAD and PHP_5_0.
Previous Comments:
[2005-05-28 14:39:46] ladislav dot prosek at matfyz dot cz
Description:
Using foreach on $this results in enumerating not only visible fields
(i.e. public and protected field declared along the inheritance
hierarchy + private fields declared in current class) but also all
private fields declared along the inheritance hierarchy. This is wrong
since those fields are not visible and should not be accessible.
By the way, the foreach documentation page still says "foreach works
only on arrays...". Perhaps you should consider updating it ;-)
Reproduce code:
---
class A
{
private $c = "A's c";
}
class B extends A
{
private $c = "B's c";
public function go()
{
foreach ($this as $key => $val)
{
echo "$key => $val\n";
}
}
};
$x = new B;
$x->go();
Expected result:
c => B's c
Actual result:
--
c => B's c
c => A's c
--
Edit this bug report at http://bugs.php.net/?id=33171&edit=1
#32993 [Asn->Csd]: implemented Iterator function current() don't throw exception
ID: 32993
Updated by: [EMAIL PROTECTED]
Reported By: vojtech at x dot cz
-Status: Assigned
+Status: Closed
Bug Type: Zend Engine 2 problem
Operating System: *
PHP Version: 5.0.4
Assigned To: helly
New Comment:
Fixed in CVS HEAD. It was already fixed in PHP_5_0.
Previous Comments:
[2005-05-31 11:21:52] tjerk dot meesters at gmail dot com
I've had a similar problem, this time with an exception in next():
class MyIterator implements Iterator
{
function rewind() {}
function next() { throw new Exception('next()'); }
function valid() { return true; }
function current() { return 'test'; }
function key() { return 'test'; }
}
try {
foreach (new MyIterator() as $x => $y) {
// do something
}
} catch (Exception $e) {
echo "{$e->getMessage()}\n";
}
--- result ---
Fatal error: Couldn't execute method MyIterator::valid in Unknown on
line 0
--- version ---
PHP 5.0.4 (cli) on Linux (Zend Engine v2.0.4-dev)
[2005-05-10 08:46:49] [EMAIL PROTECTED]
Results in a SEGV in head
[2005-05-10 06:17:40] vojtech at x dot cz
Description:
It's seems there is not correctly processed exception from current()
and script ends up with fatal error.
Reproduce code:
---
class Test implements Iterator {
public $arr = array();
public function rewind(){ return reset($this->arr); }
public function current() { throw new Exception(); }
public function key() { return key($this->arr); }
public function next() { return next($this->arr); }
public function valid() { return (current($this->arr) !==
false); }
}
$t = new Test();
$t->arr = array(1, 2, 3);
try {
foreach ($t as $v) {
; // do something
}
} catch (Exception $e) {
; // handle exception
}
Actual result:
--
Fatal error: Couldn't execute method Test::key in Unknown on line 0
--
Edit this bug report at http://bugs.php.net/?id=32993&edit=1
#32596 [Ver->Csd]: Segfault/Memory Leak by getClass (etc) in __destruct
ID: 32596
Updated by: [EMAIL PROTECTED]
Reported By: mailfrom-bugs dot php dot net at kopka dot net
-Status: Verified
+Status: Closed
Bug Type: Zend Engine 2 problem
Operating System: *
PHP Version: 5.0.CVS-2005-04-28
New Comment:
fixed in CVS PHP_5_0. It was already fixed in HEAD with new garbage
collector.
Previous Comments:
[2005-04-21 14:04:06] [EMAIL PROTECTED]
It doesn't matter which function you use there.
I get the same result with $c=substr('qeqwe',3); instead of
$c=get_class($this);
[2005-04-19 00:51:29] mailfrom-bugs dot php dot net at kopka dot net
PHP-5.1.0-dev (build Apr 10 2005) is free of this problem.
[2005-04-05 20:09:19] mailfrom-bugs dot php dot net at kopka dot net
Description:
getClass($this) and others segfault or leak memory (when
--enable-debug) on
PHP 5.0.3
PHP 5.0.4
PHP 5.0.5-dev (cli) (2005-04-05 11:42:27)
build on gentoo linux (default install flags).
I ran into this using the following construct:
if (database::query($string)->error) {}
where database::query() returns an object wrapping a result set (or
providing info on success of the request).
PHP 5.0.3 (and i am quite sure this applies to other versions as well
as i experience this for quite a time) segfaults under the following
cumulating circumstances:
- If the object is only used once and not referenced to a variable
- If a property is read/set (if a function is called all is OK)
- If __destruct references the class name by some means (others are
OK)
When you try the demo uncomment one of the lines which cause a segfault
(and are noted as a memory leak with --enable-debug):
// $c=get_class($this);unset ($c);
// echo get_class($this);
// if(defined('DEBUG_'.__CLASS__)){}
The following lines don't raise a segfault:
$c=__CLASS__;unset($c);
if(__CLASS__ == "BUG") {};
get_class($this);
echo __CLASS__;
The following line don't raise a segfault but is noted as a memory leak
(--enable-debug):
$c=get_class($this);
Naturally the hidden beast came up a long time after i wrote the line -
spending a good month of free time trying to locate it i am happy to
finally nail it to the ground for someone who knows what he is doing to
slay it (it cost me a keyboard and brought quite a few white hairs into
existence).
Since the original bug report vanished from the bug list (and can only
be found by number for reasons that escape me) i opened it again (and
closed the other).
Good hunting.
Configure Command => './configure' '--prefix=/usr'
'--host=i686-pc-linux-gnu' '--mandir=/usr/share/man'
'--infodir=/usr/share/info' '--datadir=/usr/share' '--sysconfdir=/etc'
'--localstatedir=/var/lib' '--disable-cgi' '--enable-cli'
'--enable-embed' '--with-config-file-path=/etc/php/cli-php5'
'--disable-bcmath' '--without-bz2' '--disable-calendar'
'--without-cpdflib' '--disable-ctype' '--without-curl'
'--without-curlwrappers' '--disable-dbase' '--disable-dio'
'--disable-dom' '--disable-exif' '--without-fam' '--without-fbsql'
'--without-fdftk' '--disable-filepro' '--disable-ftp'
'--without-gettext' '--without-gmp' '--without-hwapi' '--without-iconv'
'--without-informix' '--without-ingres' '--without-interbase'
'--without-kerberos' '--disable-libxml' '--disable-mbstring'
'--without-mcrypt' '--without-mcve' '--disable-memory-limit'
'--without-mhash' '--without-mime-magic' '--without-ming'
'--without-mnogosearch' '--without-msql' '--without-mssql'
'--without-ncurses' '--without-oci8' '--without-oracle'
'--without-openssl' '--without-openssl-dir' '--without-ovrimos'
'--disable-pcntl' '--without-pcre-regx' '--without-pfpro'
'--without-pgsql' '--disable-posix' '--without-pspell'
'--without-recode' '--disable-simplexml' '--disable-shmop'
'--without-snmp' '--disable-soap' '--disable-sockets' '--disable-spl'
'--without-sybase' '--without-sybase-ct' '--disable-sysvmsg'
'--disable-sysvsem' '--disable-sysvshm' '--without-tidy'
'--disable-tokenizer' '--disable-wddx' '--without-xsl'
'--without-xmlrpc' '--disable-yp' '--without-zlib' '--disable-debug'
'--without-jpeg-dir' '--without-freetype-dir' '--without-t1lib'
'--without-ttf' '--disable-gd-jis-conf' '--disable-gd-native-ttf'
'--without-png-dir' '--without-tiff-dir' '--without-xpm-dir'
'--without-gd' '--disable-session' '--without-sqlite' '--disable-dba'
'--without-readline' '--without-libedit'
Reproduce code:
---
error;
}
}
BUG::instance()->error;
echo "this is still executed\n";
?>
Expected result:
Expected result:
# php -n bug.php(cr)
please fix this thing, it wasted a nice part of my life!
this is still executed
# (cursor)
Actual result:
--
Sorry that i can not provide a core dump according to the requested
standards (vi
#32799 [Ver->Csd]: crash: calling the corresponding global var during the destruct
ID: 32799
Updated by: [EMAIL PROTECTED]
Reported By: rd dot contact at free dot fr
-Status: Verified
+Status: Closed
Bug Type: Zend Engine 2 problem
Operating System: *
PHP Version: 5CVS-2005-04-25
New Comment:
Fixed in CVS HEAD and PHP_5_0.
Previous Comments:
[2005-04-22 19:34:46] rd dot contact at free dot fr
/*
-- TEST 1
I use the global var instead of "$this" to demonstrate
that calling it will segfault php.
Try TEST2 to see why it could be useful to use the global
var during the destruct.
unset($p) instead of $p=[anything], don't crash.
*/
class test{
public $c=1;
function __destruct (){
$GLOBALS['p']->c++; // no warning
print $GLOBALS['p']->c; // segfault
}
}
$p=new test;
$p=null; //destroy the object by a new assignment (segfault)
//---CUT
/*
-- TEST 2
More realistic example:
During the destruct, I need to call an external function
that uses the global var of the object.
calling a methode: works
incrementing a property: segfault
*/
function dbug($msg){
$GLOBALS['p']->printmsg($msg); // works
$GLOBALS['p']->c++; // segfault
}
class test{
public $c=1;
function __destruct (){dbug('Destruct');}
function printmsg($msg){print $msg;}
}
$p=new test;
$p=null; //destroy the object by a new assignment (segfault)
[2005-04-22 14:31:18] [EMAIL PROTECTED]
Can you give a bit more realistic example script?
The one here does not make any sense..
[2005-04-22 05:19:51] rd dot contact at free dot fr
Description:
During the __destruct, when using the global var assigned to the
object, php crashes in some cases.
Reproduce code:
---
class test{
function __destruct (){
//$GLOBALS['p']=$this; // <- this crash apache for all tests
//$GLOBALS['p']++; // <- this crash apache for all tests
print_r($GLOBALS['p']); // <- crash only test 1. test 2 =>
"Undefined variable p"
}
}
$p=new test;
//test 1
$p=1; // crash apache (as $p=null, $p='bug', $p=new test ...)
//but,
//test 2
//unset($p); // no crash: "Undefined variable: p on line 5"
Expected result:
No crash, and a way to use the global var during destruct.
(so destruct could call external functions that use the global var of
the object. Why not unregister the global var after the destruct call
?)
--
Edit this bug report at http://bugs.php.net/?id=32799&edit=1
#32428 [Ver->Csd]: The @ warning error supression operator is broken
ID: 32428 Updated by: [EMAIL PROTECTED] Reported By: jason at amp-design dot net -Status: Verified +Status: Closed Bug Type: Zend Engine 2 problem Operating System: Cent OS 3 PHP Version: 5CVS-2005-03-23 (dev) New Comment: Fixed in CVS HEAD. Previous Comments: [2005-03-23 16:46:55] [EMAIL PROTECTED] I can confirm this issue. (reproducible in HEAD only) [2005-03-23 13:46:53] jason at amp-design dot net Description: The @ operator that is used to supress errors about warnings and other non critical errors such as notices seems to be broken in this mornings snapshot of 5.1.0. This is quite fustrating as it's handy to use the @ operator when you want pass NULL when the variable doesn't exist. Reproduce code: --- Expected result: $data is assigned with NULL without an error message Actual result: -- Notice: Undefined variable: not_exists in /data/web/tools/iq_framework/test.php on line 1 -- Edit this bug report at http://bugs.php.net/?id=32428&edit=1
#33243 [Asn->Csd]: ze1_compatibility_mode does not work as expected
ID: 33243
Updated by: [EMAIL PROTECTED]
Reported By: ladislav dot prosek at matfyz dot cz
-Status: Assigned
+Status: Closed
Bug Type: Zend Engine 2 problem
Operating System: *
PHP Version: 5.* (2005-06-07)
Assigned To: dmitry
New Comment:
Fixed in CVS HEAD and PHP_5_0.
Previous Comments:
[2005-06-06 23:59:28] [EMAIL PROTECTED]
Dmitry, can you check this one out too? (I thought something like this
was fixed already but apparently not)
[2005-06-06 18:30:44] ladislav dot prosek at matfyz dot cz
Still the same. Only the top-level object is cloned.
[2005-06-05 15:00:28] [EMAIL PROTECTED]
Please try using this CVS snapshot:
http://snaps.php.net/php5-STABLE-latest.tar.gz
For Windows:
http://snaps.php.net/win32/php5.0-win32-latest.zip
[2005-06-04 20:12:43] ladislav dot prosek at matfyz dot cz
Description:
When zend.ze1_compatibility_mode is On, object copying is not compliant
to PHP4. Namely, objects are not deep-copied on assignment. This may
cause substantial problems to legacy applications that rely on the
compatibility mode.
Reproduce code:
---
$a->y->z = 0;
$b = $a; // should perform deep copy of $a
$b->y->z = 1; // hence this should have no effect on $a
var_dump($a);
Expected result:
object(stdClass)#1 (1) {
["y"]=>
object(stdClass)#2 (1) {
["z"]=>
int(0) // <--
}
}
Actual result:
--
object(stdClass)#1 (1) {
["y"]=>
object(stdClass)#2 (1) {
["z"]=>
int(1) // because $a->y and $b->y are still one object after the
assignment
}
}
--
Edit this bug report at http://bugs.php.net/?id=33243&edit=1
#31725 [Asn]: sqlite/zend engine 2 weird problems
ID: 31725 Updated by: [EMAIL PROTECTED] Reported By: [EMAIL PROTECTED] Status: Assigned Bug Type: Zend Engine 2 problem Operating System: * PHP Version: 5CVS-2005-03-21 Assigned To: wez New Comment: Probably this bug should be fixed in CVS HEAD and PHP_5_0 with the following patch: http://cvs.php.net/diff.php/php-src/ext/sqlite/sqlite.c?r1=1.146.2.6&r2=1.146.2.7&ty=u Previous Comments: [2005-04-26 23:12:09] [EMAIL PROTECTED] Sorry, valgrind took a while to finish. The output: http://mega.ist.utl.pt/~ncpl/valgrind-php.txt [2005-04-26 20:26:06] [EMAIL PROTECTED] valgrind... [2005-04-26 20:02:44] [EMAIL PROTECTED] Well, I've already posted 2 examples with backtraces above. I've run the ini-update.php script (available in the above URL) and I got this: #0 0x4046dd67 in mallopt () from /lib/libc.so.6 #1 0x4046db5e in mallopt () from /lib/libc.so.6 #2 0x4046c908 in free () from /lib/libc.so.6 #3 0x081ea0e7 in shutdown_memory_manager (silent=0, full_shutdown=0) at /cvs/php-src/Zend/zend_alloc.c:511 #4 0x081c9821 in php_request_shutdown (dummy=0x0) at /cvs/php-src/main/main.c:1228 #5 0x082633df in main (argc=2, argv=0xb944) at /cvs/php-src/sapi/cli/php_cli.c:1057 [2005-04-22 04:46:36] [EMAIL PROTECTED] backtrace and/or valgrind output please. [2005-04-21 20:21:52] [EMAIL PROTECTED] It segfaults in both windows (using the 'official' binaries) and linux. The program that I've used that is segfaulting is in CVS: http://cvs.php.net/phpdoc/scripts/iniupdate/ The remainder of the comments for this report are too long. To view the rest of the comments, please view the bug report online at http://bugs.php.net/31725 -- Edit this bug report at http://bugs.php.net/?id=31725&edit=1
#26456 [Ver->Csd]: Wrong results from Reflection-API getDocComment() when called via STDIN
ID: 26456
Updated by: [EMAIL PROTECTED]
Reported By: schlueter at phpbar dot de
-Status: Verified
+Status: Closed
Bug Type: Zend Engine 2 problem
Operating System: linux
PHP Version: 5CVS-2004-03-15
New Comment:
Fixed in CVS HEAD and PHP_5_0.
Previous Comments:
[2005-04-22 16:30:15] [EMAIL PROTECTED]
Seems like a compiler problem to me.
That's what I got when running the script via STDIN:
1314if (fptr->type == ZEND_USER_FUNCTION &&
fptr->op_array.doc_comment) {
(gdb) p fptr->op_array.doc_comment
$1 = 0x82ce2dc "\n function increment"
If the script is run via `php script.php` fptr->op_array.doc_comment
contains expected value (i.e. the comment itself, without any garbage
data).
[2003-11-30 04:28:55] [EMAIL PROTECTED]
Thank you for the explanation. (I've never ever run scripts like this
:). Verified..and here's short example script to test this:
getDocComment();
echo "\n--\n";
?>
Bad output (with "# php && paste script && ctrl+d):
--
function increment)
*
* @access public
* @return int
*/
--
Good output:
--
/**
* Increment counter
*
* @access public
* @return int
*/
--
[2003-11-29 09:15:15] schlueter at phpbar dot de
I've tested now with php5-200311291230 (simply ./configure without any
paramters) and get the same results. And the exact way I'm runnig PHP
ist this:
1. I'm opening a shell window
2. $ ./php [return]
3. I put the source into the clipboard
4. I paste it into the shell window
5. Ctrl+D
6. Wrong results (see original report) appear
I hope now it's clear how I'm doing it.
I've just tested it on another Linux machine: Same results...
[2003-11-28 20:32:22] [EMAIL PROTECTED]
Please try using this CVS snapshot:
http://snaps.php.net/php5-latest.tar.gz
For Windows:
http://snaps.php.net/win32/php5-win32-latest.zip
..and show exactly HOW you run it when it doesn't work,
[2003-11-28 17:07:52] schlueter at phpbar dot de
Description:
While testing the examples from
http://sitten-polizei.de/php/reflection_api/docs/language.reflection.html
I found a (for me) unexpected beahvior with
Reflection_Function::getDocComment() and
Reflection_Method::getDocComment() the when calling PHP on the command
line without paramter and copying a test script into my shell window, so
PHP can read it from STDIN. If I call the same script from a file or
pipe (cat test.php | /opt/php5/bin/php) all seems to work.
Reproduce code:
---
Example 14-5 from
http://sitten-polizei.de/php/reflection_api/docs/language.reflection.class.reflection_method.html
Expected result:
===> The user-defined final public static method 'increment' (which is
a regular method)
declared in -
lines 13 to 17
having the modifiers 261[final public static]
---> Documentation:
'/**
* Increment counter
*
* @final
* @static
* @access public
* @return int
*/'
---> Invokation results in: int(1)
Actual result:
--
===> The user-defined final public static method 'increment' (which is
a regular method)
declared in /home/johannes/-
lines 13 to 17
having the modifiers 261[final public static]
---> Documentation:
'
final public static function increment)
final
* @static
* @access public
* @return int
*/'
---> Invokation results in: int(1)
--
Edit this bug report at http://bugs.php.net/?id=26456&edit=1
#30961 [Asn->Csd]: Wrong linenumber in ReflectionClass getStartLine()
ID: 30961 Updated by: [EMAIL PROTECTED] Reported By: michiel at trendserver dot nl -Status: Assigned +Status: Closed Bug Type: Zend Engine 2 problem Operating System: * PHP Version: 5CVS-2005-03-01 Assigned To: helly New Comment: Fixed in CVS HEAD and PHP_5_0. Previous Comments: [2005-03-30 23:10:29] [EMAIL PROTECTED] Assigning to the author. [2005-03-01 09:39:47] michiel at trendserver dot nl No change, using either http://snaps.php.net/win32/php5.0-win32-200503010130.zip or http://snaps.php.net/win32/php5-win32-200503010730.zip (can not confirm using a *nix build at this time) [2005-02-28 21:20:15] [EMAIL PROTECTED] Please try using this CVS snapshot: http://snaps.php.net/php5-latest.tar.gz For Windows: http://snaps.php.net/win32/php5-win32-latest.zip [2004-12-02 14:27:21] michiel at trendserver dot nl Description: The Reflection API has a (minor) bug regarding the getStartLine() function in ReflectionClass. When the reflected class is not a subclass and does not implement any interfaces, the result of getStartLine() is one line off. Reproduce code: --- getStartLine() . "\n"; echo $ref2->getStartLine() . "\n"; ?> Expected result: 2 6 Actual result: -- 3 6 -- Edit this bug report at http://bugs.php.net/?id=30961&edit=1
#30820 [Asn->Csd]: static member conflict with $this->member silently ignored
ID: 30820 Updated by: [EMAIL PROTECTED] Reported By: levi at alliancesoftware dot com dot au -Status: Assigned +Status: Closed Bug Type: Zend Engine 2 problem Operating System: * PHP Version: 5CVS-2005-03-06 Assigned To: andi New Comment: Fixed in CVS HEAD and PHP_5_0. Previous Comments: [2004-11-18 02:40:09] levi at alliancesoftware dot com dot au Description: If you declare a static data member (eg x), $this->x refers to a different variable without generating any warnings. Arguably, the proper behavior when setting a class variable through $this should first be to check if there are any static member variables of the same name and *then* check for instantiated member variables. Reproduce code: --- #!/usr/local/bin/php5 -q x = 5; // no warning, but refers to different variable echo ' Blah::$x = '. Blah::$x ."\n"; echo '$ this->x = '. $this->x ."\n"; } } $b = new Blah(); $b->show(); ?> Expected result: either: (preferable) Blah::$x = 5 $this->x = 5 -or- at the minimum, display a warning Actual result: -- Blah::$x = 1 $this->x = 5 -- Edit this bug report at http://bugs.php.net/?id=30820&edit=1
#32322 [Opn->Csd]: Return values by reference broken( using self::),example singleton instance
ID: 32322
Updated by: [EMAIL PROTECTED]
Reported By: rickd at commando-pernod dot net
-Status: Open
+Status: Closed
Bug Type: Zend Engine 2 problem
Operating System: Win2000
PHP Version: 5CVS-2005-03-19
New Comment:
This bug is already fixed in CVS HEAD and PHP_5_0.
Previous Comments:
[2005-03-20 06:07:13] rickd at commando-pernod dot net
myname = $value;
}
private function __clone() {}
static public function getInstance()
{
if ( self::$instance == null )
{
self::$instance = new test('Singleton1');
}
else {
echo "Using old class " . self::$instance -> myname .
"\n";
}
return self::$instance;
}
static public function getInstance2()
{
static $instance2 = null;
if ( $instance2 == null )
{
$instance2 = new test('Singleton2');
}
else {
echo "Using old class " . $instance2 -> myname . "\n";
}
return $instance2;
}
public function __destruct()
{
if ( defined('SCRIPT_END') )
{
echo "Class " . $this -> myname . " destroyed at script end
\n";
} else {
echo "Class " . $this -> myname . " destroyed beforce
script end \n";
}
}
}
echo "Try static instance inside class :\n";
$getCopyofSingleton= test::getInstance();
$getCopyofSingleton= null;
$getCopyofSingleton= &test::getInstance();
$getCopyofSingleton= null;
$getCopyofSingleton= test::getInstance();
echo "Try static instance inside function :\n";
$getCopyofSingleton2 = test::getInstance2();
$getCopyofSingleton2 = null;
$getCopyofSingleton2 = &test::getInstance2();
$getCopyofSingleton2 = null;
$getCopyofSingleton2 = test::getInstance2();
define('SCRIPT_END',1);
?>
Current result :
Try static instance inside class :
New class Singleton1 created
Using old class Singleton1
Class Singleton1 destroyed beforce script end
New class Singleton1 created
Try static instance inside function :
New class Singleton2 created
Using old class Singleton2
Using old class Singleton2
Class Singleton1 destroyed at script end
Class Singleton2 destroyed at script end
Expected result :
Try static instance inside class :
New class Singleton1 created
Using old class Singleton1
Using old class Singleton1
Try static instance inside function :
New class Singleton2 created
Using old class Singleton2
Using old class Singleton2
Class Singleton1 destroyed at script end
Class Singleton2 destroyed at script end
php setting :
allow_call_time_pass_reference Off Off
zend.ze1_compatibility_mode Off Off
What i mean whats going wrong :
to return a variable by reference, you need to define the caller´s code
and function code with a & prefix, but it seems when you use the self::
and parent:: as return values
this is broken, only caller need a & prefix, that is what i mean
[2005-03-19 21:49:04] [EMAIL PROTECTED]
Please provide an example script that actually returns something. And
give the expected / actual results too.
[2005-03-15 19:54:01] rickd at commando-pernod dot net
Description:
We use a user singleton instance for our cms user authed ids that
should not be able to killed from third party addons or worse coders so
easily, but accessable from all.
But when someone get the instance with reference it can be killed easy
with setting the reference var to null, unset dont work.
If you put the static $instance holder inside the getinstance()
function it seems to be work correct and cant be deleted from setting
reference to NULL
Reproduce code:
---
class test {
static private $instance = null;
static function getinstance() {
if ( self::$instance == null ) {
return new test();
}
return self::$instance;
}
}
$user = &test::getinstance();
$user = null; // destroy singleton instance
$user = &test::getinstance();
unset( $user ); // dont destroy instance
Expected result:
singleton not destroying with setting a getted instance with
reference to null
Actual result:
--
singleton destroyed
--
Edit this bug report at http://bugs.php.net/?id=32322&edit=1
#30140 [WFx->Asn]: Problem with array in static properties
ID: 30140
Updated by: [EMAIL PROTECTED]
Reported By: guth at fiifo dot u-psud dot fr
-Status: Wont fix
+Status: Assigned
Bug Type: Zend Engine 2 problem
Operating System: *
PHP Version: 5CVS-2005-05-07
-Assigned To: andi
+Assigned To: dmitry
New Comment:
No this is another bug. The problem is in zval_update_constant().
Reproduce code:
---
Expected result:
string(1) "x"
string(1) "y"
string(1) "z"
string(1) "x"
string(1) "y"
string(1) "z"
Actual result:
--
string(1) "x"
string(1) "y"
string(1) "z"
bool(true)
array(0) {
}
string(1) "z"
Previous Comments:
[2005-05-17 16:27:37] [EMAIL PROTECTED]
It's definitely duplicate for bug #30934.
[2005-05-09 11:34:31] [EMAIL PROTECTED]
This same thing happens with boolean too. All other types behave
correctly (or incorrectly, not sure anymore :)
Andi, (or Dmitry maybe?) can you look into this?
[2005-04-05 23:24:10] [EMAIL PROTECTED]
Yet another duplicate of bug #30934.
[2004-09-18 17:02:22] guth at fiifo dot u-psud dot fr
Description:
[ sorry for english ]
There is a problem with static properties initialized as
an array in classes.
In the following code, if you replace "public static $test
= array();" by "public static $test;" or if you initialize
the property with not an array ("public static $test =
12;" for example), it works as expected.
Reproduce code:
---
set(array('key' => 'value'));
A::view();
B::view();
?>
Expected result:
array(1) { ["key"]=> string(5) "value" }
array(1) { ["key"]=> string(5) "value" }
Actual result:
--
array(1) { ["key"]=> string(5) "value" }
array(0) { }
--
Edit this bug report at http://bugs.php.net/?id=30140&edit=1
#30140 [Asn->Csd]: Problem with array in static properties
ID: 30140
Updated by: [EMAIL PROTECTED]
Reported By: guth at fiifo dot u-psud dot fr
-Status: Assigned
+Status: Closed
Bug Type: Zend Engine 2 problem
Operating System: *
PHP Version: 5CVS-2005-05-07
Assigned To: dmitry
New Comment:
Fixed in CVS HEAD and PHP_5_0.
Previous Comments:
[2005-06-08 11:18:53] [EMAIL PROTECTED]
No this is another bug. The problem is in zval_update_constant().
Reproduce code:
---
Expected result:
string(1) "x"
string(1) "y"
string(1) "z"
string(1) "x"
string(1) "y"
string(1) "z"
Actual result:
--
string(1) "x"
string(1) "y"
string(1) "z"
bool(true)
array(0) {
}
string(1) "z"
[2005-05-17 16:27:37] [EMAIL PROTECTED]
It's definitely duplicate for bug #30934.
[2005-05-09 11:34:31] [EMAIL PROTECTED]
This same thing happens with boolean too. All other types behave
correctly (or incorrectly, not sure anymore :)
Andi, (or Dmitry maybe?) can you look into this?
[2005-04-05 23:24:10] [EMAIL PROTECTED]
Yet another duplicate of bug #30934.
[2004-09-18 17:02:22] guth at fiifo dot u-psud dot fr
Description:
[ sorry for english ]
There is a problem with static properties initialized as
an array in classes.
In the following code, if you replace "public static $test
= array();" by "public static $test;" or if you initialize
the property with not an array ("public static $test =
12;" for example), it works as expected.
Reproduce code:
---
set(array('key' => 'value'));
A::view();
B::view();
?>
Expected result:
array(1) { ["key"]=> string(5) "value" }
array(1) { ["key"]=> string(5) "value" }
Actual result:
--
array(1) { ["key"]=> string(5) "value" }
array(0) { }
--
Edit this bug report at http://bugs.php.net/?id=30140&edit=1
#25922 [Csd->Asn]: In error handler, modifying 5th arg (errcontext) may result in seg fault
ID: 25922
Updated by: [EMAIL PROTECTED]
Reported By: jeroen at derks dot it
-Status: Closed
+Status: Assigned
Bug Type: Scripting Engine problem
Operating System: Linux 2.4.20 Debian 3.0
PHP Version: 4-STABLE-CVS-20031021
-Assigned To:
+Assigned To: dmitry
New Comment:
The bug is still reprodusabe in PHP_4_4 and HEAD.
Previous Comments:
[2003-10-22 19:49:40] [EMAIL PROTECTED]
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-10-21 06:16:08] [EMAIL PROTECTED]
With PHP 4.3.4RC3-dev:
[Tue Oct 21 13:11:19 2003] Script: 't.php'
---
zend_opcode.c(152) : Block 0x08508470 status:
Beginning: Overrun (magic=0x084E8D58, expected=0x7312F8DC)
End: Unknown
---
[Tue Oct 21 13:11:19 2003] Script: 't.php'
---
zend_opcode.c(159) : Block 0x08509568 status:
zend_variables.c(44) : Actual location (location was relayed)
Beginning: Overrun (magic=0x084E8D58, expected=0x7312F8DC)
End: Unknown
---
[Tue Oct 21 13:11:19 2003] Script: 't.php'
---
zend_opcode.c(159) : Block 0x085095A0 status:
zend_variables.c(44) : Actual location (location was relayed)
Beginning: Overrun (magic=0x085095D0, expected=0x7312F8DC)
End: Unknown
---
[Tue Oct 21 13:11:19 2003] Script: 't.php'
---
zend_opcode.c(165) : Block 0x085095D8 status:
zend_variables.c(44) : Actual location (location was relayed)
Beginning: Overrun (magic=0x08509608, expected=0x7312F8DC)
End: Unknown
---
[Tue Oct 21 13:11:19 2003] Script: 't.php'
---
zend_opcode.c(159) : Block 0x08509610 status:
zend_variables.c(44) : Actual location (location was relayed)
Beginning: Overrun (magic=0x08509640, expected=0x7312F8DC)
End: Unknown
---
[Tue Oct 21 13:11:19 2003] Script: 't.php'
---
zend_opcode.c(165) : Block 0x08509648 status:
zend_variables.c(44) : Actual location (location was relayed)
Beginning: Overrun (magic=0x08509678, expected=0x7312F8DC)
End: Unknown
...and so on. GDB backtrace:
Program received signal SIGSEGV, Segmentation fault.
[Switching to Thread 16384 (LWP 14715)]
0x08259de8 in _efree (ptr=0x85096b4, __zend_filename=0x8361d00
"zend_opcode.c",
__zend_lineno=169, __zend_orig_filename=0x0, __zend_orig_lineno=0)
at zend_alloc.c:259
259 REMOVE_POINTER_FROM_LIST(p);
(gdb) bt
#0 0x08259de8 in _efree (ptr=0x85096b4, __zend_filename=0x8361d00
"zend_opcode.c",
__zend_lineno=169, __zend_orig_filename=0x0, __zend_orig_lineno=0)
at zend_alloc.c:259
#1 0x08265895 in destroy_op_array (op_array=0x8508af8) at
zend_opcode.c:169
#2 0x0826566b in destroy_zend_function (function=0x8508af8) at
zend_opcode.c:100
#3 0x08272fa7 in zend_hash_destroy (ht=0x8415848) at zend_hash.c:553
#4 0x0826cb30 in zend_shutdown () at zend.c:559
#5 0x082358bf in php_module_shutdown () at main.c:1284
#6 0x08290fb0 in main (argc=2, argv=0xbc84) at php_cli.c:876
Note: Works fine with PHP 5.
[2003-10-20 14:11:56] [EMAIL PROTECTED]
Please try using this CVS snapshot:
http://snaps.php.net/php5-latest.tar.gz
For Windows:
http://snaps.php.net/win32/php5-win32-latest.zip
[2003-10-20 07:54:21] jeroen at derks dot it
Description:
Modifying 5th parameter of error handler will make PHP crash when
leaving the error handler.
NB: This seems to happen only when the error was generated in a
function (possibly also in a member function). Please see the code.
NB2: When changing function test()'s parameter name into $args, PHP
exitted normally.
Reproduce code:
---
function my_error_handler( $error, $errmsg = '', $errfile = '',
$errline = 0, $errcontext = '' )
{
$errcontext = '';
#25922 [Asn->Csd]: In error handler, modifying 5th arg (errcontext) may result in seg fault
ID: 25922 Updated by: [EMAIL PROTECTED] Reported By: jeroen at derks dot it -Status: Assigned +Status: Closed Bug Type: Scripting Engine problem Operating System: Linux 2.4.20 Debian 3.0 PHP Version: 4-STABLE-CVS-20031021 Assigned To: dmitry New Comment: Fixed in CVS HEAD, PHP_5_0 and PHP_4_4. Previous Comments: [2005-06-08 16:13:42] [EMAIL PROTECTED] The bug is still reprodusabe in PHP_4_4 and HEAD. [2003-10-22 19:49:40] [EMAIL PROTECTED] 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-10-21 06:16:08] [EMAIL PROTECTED] With PHP 4.3.4RC3-dev: [Tue Oct 21 13:11:19 2003] Script: 't.php' --- zend_opcode.c(152) : Block 0x08508470 status: Beginning: Overrun (magic=0x084E8D58, expected=0x7312F8DC) End: Unknown --- [Tue Oct 21 13:11:19 2003] Script: 't.php' --- zend_opcode.c(159) : Block 0x08509568 status: zend_variables.c(44) : Actual location (location was relayed) Beginning: Overrun (magic=0x084E8D58, expected=0x7312F8DC) End: Unknown --- [Tue Oct 21 13:11:19 2003] Script: 't.php' --- zend_opcode.c(159) : Block 0x085095A0 status: zend_variables.c(44) : Actual location (location was relayed) Beginning: Overrun (magic=0x085095D0, expected=0x7312F8DC) End: Unknown --- [Tue Oct 21 13:11:19 2003] Script: 't.php' --- zend_opcode.c(165) : Block 0x085095D8 status: zend_variables.c(44) : Actual location (location was relayed) Beginning: Overrun (magic=0x08509608, expected=0x7312F8DC) End: Unknown --- [Tue Oct 21 13:11:19 2003] Script: 't.php' --- zend_opcode.c(159) : Block 0x08509610 status: zend_variables.c(44) : Actual location (location was relayed) Beginning: Overrun (magic=0x08509640, expected=0x7312F8DC) End: Unknown --- [Tue Oct 21 13:11:19 2003] Script: 't.php' --- zend_opcode.c(165) : Block 0x08509648 status: zend_variables.c(44) : Actual location (location was relayed) Beginning: Overrun (magic=0x08509678, expected=0x7312F8DC) End: Unknown ...and so on. GDB backtrace: Program received signal SIGSEGV, Segmentation fault. [Switching to Thread 16384 (LWP 14715)] 0x08259de8 in _efree (ptr=0x85096b4, __zend_filename=0x8361d00 "zend_opcode.c", __zend_lineno=169, __zend_orig_filename=0x0, __zend_orig_lineno=0) at zend_alloc.c:259 259 REMOVE_POINTER_FROM_LIST(p); (gdb) bt #0 0x08259de8 in _efree (ptr=0x85096b4, __zend_filename=0x8361d00 "zend_opcode.c", __zend_lineno=169, __zend_orig_filename=0x0, __zend_orig_lineno=0) at zend_alloc.c:259 #1 0x08265895 in destroy_op_array (op_array=0x8508af8) at zend_opcode.c:169 #2 0x0826566b in destroy_zend_function (function=0x8508af8) at zend_opcode.c:100 #3 0x08272fa7 in zend_hash_destroy (ht=0x8415848) at zend_hash.c:553 #4 0x0826cb30 in zend_shutdown () at zend.c:559 #5 0x082358bf in php_module_shutdown () at main.c:1284 #6 0x08290fb0 in main (argc=2, argv=0xbc84) at php_cli.c:876 Note: Works fine with PHP 5. [2003-10-20 14:11:56] [EMAIL PROTECTED] Please try using this CVS snapshot: http://snaps.php.net/php5-latest.tar.gz For Windows: http://snaps.php.net/win32/php5-win32-latest.zip [2003-10-20 07:54:21] jeroen at derks dot it Description: Modifying 5th parameter of error handler will make PHP crash when leaving the error handler. NB: This seems to happen only when the error was generated in a function (possibly also in a member function). Please see the code. NB2: When changing function test()'s parameter name into $args, PHP exitted normally. Reproduce code: --- function my_error_handler( $error, $e
#33212 [Opn->Asn]: [GCC 4]: 'zend_error_noreturn' aliased to external symbol 'zend_error'
ID: 33212
Updated by: [EMAIL PROTECTED]
Reported By: daniel at comentar dot com dot br
-Status: Open
+Status: Assigned
Bug Type: Compile Failure
Operating System: *
PHP Version: 5CVS-2005-06-01 (dev)
-Assigned To:
+Assigned To: dmitry
Previous Comments:
[2005-06-10 11:46:45] [EMAIL PROTECTED]
this is the same probem reported in #30641.
As I've stated in that bug report, the code isn't standard compatible,
so we will get much more bug reports if you continue to just add the
special cases that fail to the #if statement.
Why not fix it properly? You just need to move that declaration to the
zend.c file (http://news.php.net/php.internals/15768).
[2005-06-01 17:48:31] daniel at comentar dot com dot br
Problem solved with changes on lines 47 and 48 of file zend_execute.c.
Line 47: void zend_error_noreturn(int type, const char *format, ...)
__attribute__ ((alias("zend_error"),noreturn));
Line 48: /*extern void zend_error_noreturn(int type, const char
*format, ...) __asm__("zend_error") __attribute__ ((noreturn));*/
Changed to:
Line 47: /*void zend_error_noreturn(int type, const char *format, ...)
__attribute__ ((alias("zend_error"),noreturn));*/
Line 48: extern void zend_error_noreturn(int type, const char *format,
...) __asm__("zend_error") __attribute__ ((noreturn));
[2005-06-01 17:14:38] daniel at comentar dot com dot br
Description:
Compile of PHP5CVS-200506011430 fails with:
/bin/sh /compartilhado/downloads/php/php5-200506011430/libtool --silent
--preserve-dup-deps --mode=compile gcc -IZend/
-I/compartilhado/downloads/php/php5-200506011430/Zend/ -DPHP_ATOM_INC
-I/compartilhado/downloads/php/php5-200506011430/include
-I/compartilhado/downloads/php/php5-200506011430/main
-I/compartilhado/downloads/php/php5-200506011430 -I/usr/include/libxml2
-I/compartilhado/downloads/php/php5-200506011430/TSRM
-I/compartilhado/downloads/php/php5-200506011430/Zend-g -O2 -c
/compartilhado/downloads/php/php5-200506011430/Zend/zend_execute.c -o
Zend/zend_execute.lo
/compartilhado/downloads/php/php5-200506011430/Zend/zend_execute.c:47:
error: 'zend_error_noreturn' aliased to external symbol 'zend_error'
make: *** [Zend/zend_execute.lo] Error 1
Reproduce code:
---
[EMAIL PROTECTED] php5-200506011430]# ./configure --prefix=/usr/local/php5
--enable-cli --disable-cgi
(View output in
http://www.comentar.com.br/daniel/php5/configure-PHP5-200506011430.txt)
[EMAIL PROTECTED] php5-200506011430]# make
[EMAIL PROTECTED] php5-200506011430]# gcc --version
gcc (GCC) 4.0.0 20050519 (Red Hat 4.0.0-8)
Copyright (C) 2005 Free Software Foundation, Inc.
This is free software; see the source for copying conditions. There is
NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR
PURPOSE.
--
Edit this bug report at http://bugs.php.net/?id=33212&edit=1
#33312 [Csd]: ReflectionParameter methods do not work correctly
ID: 33312
Updated by: [EMAIL PROTECTED]
Reported By: sb at sebastian-bergmann dot de
Status: Closed
Bug Type: Zend Engine 2 problem
Operating System: Windows XP
PHP Version: 5CVS-2005-06-11 (dev)
-Assigned To:
+Assigned To: dmitry
New Comment:
Fixed in CVS HEAD.
Previous Comments:
[2005-06-13 10:43:07] [EMAIL PROTECTED]
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.
[2005-06-11 16:03:12] sb at sebastian-bergmann dot de
Description:
The ReflectionParameter::isDefaultValueAvailable() and
ReflectionParameter::getDefaultValue() methods only work correctly when
the method only has one parameter.
When the method has more than one parameter,
ReflectionParameter::isDefaultValueAvailable() returns FALSE for a
parameter that has a default value and
ReflectionParameter::getDefaultValue() produces an error when trying to
access the default value.
The reproducing script below works fine with the current PHP_5_0
branch. With HEAD it prints nothing. Only after removing "Foo $foo, "
from the method signature does it print "bar".
Reproduce code:
---
getMethod('bar');
foreach ($method->getParameters() as $parameter) {
if ($parameter->isDefaultValueAvailable()) {
print $parameter->getDefaultValue();
}
}
?>
Expected result:
bar
--
Edit this bug report at http://bugs.php.net/?id=33312&edit=1
#33318 [Asn->Csd]: throw 1; results in Invalid opcode 108/1/8
ID: 33318
Updated by: [EMAIL PROTECTED]
Reported By: pornel at despammed dot com
-Status: Assigned
+Status: Closed
Bug Type: Zend Engine 2 problem
Operating System: *
PHP Version: 5CVS-2005-06-16
Assigned To: dmitry
New Comment:
Fixed in CVS HEAD.
Previous Comments:
[2005-06-16 15:33:47] [EMAIL PROTECTED]
Dmitry, please check this out. (I can reproduce with latest CVS)
[2005-06-16 14:43:54] pornel at despammed dot com
results in:
Fatal error: Invalid opcode 108/1/8. in c:\www\test.php5 on line 2
using PHP Version 5.1.0-dev Build Date Jun 15 2005 04:17:08 installed
on Win32 Apache/1.3.33 as CGI.
[2005-06-13 10:32:15] [EMAIL PROTECTED]
Please try using this CVS snapshot:
http://snaps.php.net/php5-latest.tar.gz
For Windows:
http://snaps.php.net/win32/php5-win32-latest.zip
I can not reproduce (the "script" you gave isn't really complete, is
it?)
[2005-06-12 22:45:31] pornel at despammed dot com
Description:
throw NULL; throw 1; and probably all non-object throws result in
"Invalid Opcode" errors.
if PHP isn't supposed to allow throwing of scalar values, error should
be more precise.
Reproduce code:
---
function ERR() {throw 'x';}
Expected result:
C++-like throwing of anything or parse error.
--
Edit this bug report at http://bugs.php.net/?id=33318&edit=1
#33366 [Asn->Bgs]: __soapCall Produces Incorrect Request
ID: 33366
Updated by: [EMAIL PROTECTED]
Reported By: cmantunes at gmail dot com
-Status: Assigned
+Status: Bogus
Bug Type: SOAP related
Operating System: Debian
PHP Version: 5.1.0
Assigned To: dmitry
New Comment:
Hi,
The ext/soap is match easy in usage then you expected.
You should use the following code:
$isc->getOperationCount(array(
'startDate' => '2005-04-01',
'endDate' => '2005-04-01'
));
or
$isc->__soapCall('getOperationCount', array(
array('getOperationCount' => array(
'startDate' => '2005-04-01',
'endDate' => '2005-04-01'
)));
You don't need to use SoapParam if you use WSDL.
Previous Comments:
[2005-06-16 20:33:24] cmantunes at gmail dot com
As requested, I attempted the same code with the latest snapshot
(php5-200506161630) but __soapCall continues to exhibit the same buggy
behavior as before. As such, the problem doesn't appear to have been
corrected yet. Thank you!
[2005-06-16 18:56:00] [EMAIL PROTECTED]
Please try using this CVS snapshot:
http://snaps.php.net/php5-latest.tar.gz
For Windows:
http://snaps.php.net/win32/php5-win32-latest.zip
[2005-06-16 18:44:22] cmantunes at gmail dot com
Description:
When using SoapClient->__soapCall with parameters, the request is
incorrectly encoded regarding the method parameters. The first
SoapParam is also ignored.
Reproduce code:
---
#!/usr/bin/php
https://adwords.google.com/api/adwords/v2";;
// InfoService client
$isc=new SoapClient($ns . '/InfoService?wsdl',
array('trace'=>1, 'exceptions'=>1)
);
try
{
//
// BUG: __soapCall *IGNORES* the first parameter!
// That's why 'null' is being used
//
$params=array(null,
new SoapParam('2005-04-01', 'startDate'),
new SoapParam('2005-04-30', 'endDate'));
//
// BUG: This Call produces:
// ->CLOSED ALREADY!
// 2005-04-01
// 2005-04-30
//
$isc->__soapCall('getOperationCount', $params);
}
catch (Exception $e)
{
print_r($e);
}
print "Request:\n\n" .
$isc->__getLastRequest() . "\n\n\n";
print "Response:\n\n" .
$isc->__getLastResponse() . "\n\n\n";
?>
Expected result:
2005-04-01
2005-04-30
Actual result:
--
2005-04-01
2005-04-30
--
Edit this bug report at http://bugs.php.net/?id=33366&edit=1
#33277 [Asn->Csd]: private method accessed by child class
ID: 33277
Updated by: [EMAIL PROTECTED]
Reported By: [EMAIL PROTECTED]
-Status: Assigned
+Status: Closed
Bug Type: Zend Engine 2 problem
Operating System: *
PHP Version: 5CVS-2005-06-08 (dev)
Assigned To: stas
New Comment:
Fixed in CVS HEAD and PHP_5_0.
Previous Comments:
[2005-06-08 18:32:43] [EMAIL PROTECTED]
Description:
Code below produces "private!" - meaning that object is allowed to
access private methods of the parent class, which is, of course, wrong.
Reproduce code:
---
bar();
}
}
class foo2son extends fooson {
function bar() {
echo "public!\n";
}
}
$b = new foo2son();
$b->barson();
?>
Expected result:
public!
Actual result:
--
private!
--
Edit this bug report at http://bugs.php.net/?id=33277&edit=1
#31402 [Ver->Csd]: unserialize creates a field containing a reference when it should not
ID: 31402
Updated by: [EMAIL PROTECTED]
Reported By: otto at efficiency-online dot nl
-Status: Verified
+Status: Closed
Bug Type: Scripting Engine problem
Operating System: *
PHP Version: 5CVS, 4CVS (2005-01-18)
-Assigned To:
+Assigned To: dmitry
New Comment:
Fixed in PHP_4_4.
It was already fixed in HEAD and PHP_5_0.
Previous Comments:
[2005-01-04 09:22:55] otto at efficiency-online dot nl
Description:
An object having a field initialized to a element of an array in the
same object is transformed into a reference after unserializing. I had
a session object exposing this problem and managed to create a code
snippet exposing the problem. After the assignment to the field $y->B,
the array should not have changed, but it is changed.
It looks like $y->B has become a reference to $y->A[1] after the
unserialize call. This is a regression wrt to 4.3.9 and might be
related to bug Bug #31213.
Reproduce code:
---
i = $i;
}
}
class Y {
var $A = array();
var $B;
function x() {
$this->A[1] = new X(1);
$this->A[2] = new X(2);
$this->B = $this->A[1];
}
}
$x = new Y();
$x->x();
echo "original object:\n";
print_r($x);
$ser = serialize($x);
$y = unserialize($ser);
echo "after unserialize:\n";
print_r($y);
$y->B = $y->A[2];
echo "after assignment:\n";
print_r($y);
?>
Expected result:
// result with 4.3.9
original object:
y Object
(
[A] => Array
(
[1] => x Object
(
[i] => 1
)
[2] => x Object
(
[i] => 2
)
)
[B] => x Object
(
[i] => 1
)
)
after unserialize:
y Object
(
[A] => Array
(
[1] => x Object
(
[i] => 1
)
[2] => x Object
(
[i] => 2
)
)
[B] => x Object
(
[i] => 1
)
)
after assignment:
y Object
(
[A] => Array
(
[1] => x Object
(
[i] => 1
)
[2] => x Object
(
[i] => 2
)
)
[B] => x Object
(
[i] => 2
)
)
Actual result:
--
// result with 4.3.10
y Object
(
[A] => Array
(
[1] => x Object
(
[i] => 1
)
[2] => x Object
(
[i] => 2
)
)
[B] => x Object
(
[i] => 1
)
)
after unserialize:
y Object
(
[A] => Array
(
[1] => x Object
(
[i] => 1
)
[2] => x Object
(
[i] => 2
)
)
[B] => x Object
(
[i] => 1
)
)
after assignment:
y Object
(
[A] => Array
(
[1] => x Object
(
[i] => 2
)
[2] => x Object
(
[i] => 2
)
)
[B] => x Object
(
[i] => 2
)
)
--
Edit this bug report at http://bugs.php.net/?id=31402&edit=1
#33061 [Asn->Bgs]: Pass object by value then modify initialized sub-object: passes by reference
ID: 33061 Updated by: [EMAIL PROTECTED] Reported By: online at natweiss dot com -Status: Assigned +Status: Bogus Bug Type: Class/Object related Operating System: * PHP Version: 5CVS-2005-06-19 Assigned To: dmitry New Comment: PHP5 always pass and assign objects by reference. You should set "zend.ze1_compatibility_mode=1" if you like PHP4 behavior. Previous Comments: [2005-06-19 02:12:55] [EMAIL PROTECTED] ATTENTION: This does NOT happen with PHP_4_4 !! Simplified example: val = 1; } $object = new something; var_dump($object); pass_by_value($object); var_dump($object); ?> Expected result: int(0) int(0) Actual result: -- int(0) int(1) [2005-05-19 02:39:30] online at natweiss dot com Description: See reproduce code. php.ini is stock / no changes. Reproduce code: --- member->val = 1; } // create a something with a member something $object = new something; $object->member = new something; // call nothing, then call pass_by_value and print results $object->member->nothing(); echo "member->val should be empty!\n"; pass_by_value($object); print_r($object); ?> Expected result: $object->member should be empty Actual result: -- $object->member->val == 1 -- Edit this bug report at http://bugs.php.net/?id=33061&edit=1
#31213 [Asn]: Fix for #29493 seem to have caused other errors
ID: 31213
Updated by: [EMAIL PROTECTED]
Reported By: mikael at SPAMMENOTchl dot chalmers dot se
Status: Assigned
Bug Type: Scripting Engine problem
Operating System: *
PHP Version: 4CVS-2005-06-08 (only!)
Assigned To: dmitry
New Comment:
Fixed in CVS HEAD, PHP_5_0 and PHP_4_4.
Previous Comments:
[2005-06-18 04:10:37] [EMAIL PROTECTED]
That test seems to fail in HEAD now too..
[2005-06-14 09:31:44] [EMAIL PROTECTED]
I discussed this briefly with Dmitry - it's not an easy fix and
touching it creates other problems. We decided to suspend it until
we've more time to look at it.
[2005-01-19 22:11:51] [EMAIL PROTECTED]
See also bug #31217 and bug #30074
[2004-12-21 00:11:04] mikael at SPAMMENOTchl dot chalmers dot se
Description:
In regard to bug #29493 (would have added a comment to it if I could)
--
This fix seems to have been backported to PHP 4.3.9, now we get other
errors.
In the example below $acopy is a reference to $arr['acopy'] and $a is
also a reference to $arr['acopy'], when actually $a should have been
separated from $arr['acopy'] when extract() makes the $acopy reference
to $arr['acopy'] since the array is created with 'acopy' => $a
$b, $arr['bref'] and $bref should and does however all point to the
same value as they should since the array is created with 'bref' =>
&$b
Reproduce code:
Reproduce code:
---
$a = 1; $b = 1;
$arr = array('acopy' => $a, 'bref' => &$b);
extract($arr, EXTR_REFS);
$acopy++;
$bref++;
debug_zval_dump($a, $b, $arr, $acopy, $bref);
Expected result:
(As seen on PHP < 4.3.9):
$a: long(1) refcount(2)
$b: long(2) refcount(1)
$arr: array(2) refcount(2){
["acopy"]=>
&long(2) refcount(2)
["bref"]=>
&long(2) refcount(3)
}
$acopy: long(2) refcount(1)
$bref: long(2) refcount(1)
Note: Shouldn't the refcount of $a be == 1 instead of 2. $a should be a
separate zval while $arr['acopy'] and $acopy should be references to the
same value as indicated by the refcount of 2
Actual result:
--
$a is now == 2, when it should be == 1. Only $arr['acopy'] should be ==
2
$a: long(2) refcount(1)
$b: long(2) refcount(1)
$arr: array(2) refcount(2){
["acopy"]=>
&long(2) refcount(3)
["bref"]=>
&long(2) refcount(3)
}
$acopy: long(2) refcount(1)
$bref: long(2) refcount(1)
--
Edit this bug report at http://bugs.php.net/?id=31213&edit=1
#31213 [Asn->Csd]: Fix for #29493 seem to have caused other errors
ID: 31213
Updated by: [EMAIL PROTECTED]
Reported By: mikael at SPAMMENOTchl dot chalmers dot se
-Status: Assigned
+Status: Closed
Bug Type: Scripting Engine problem
Operating System: *
PHP Version: 4CVS-2005-06-08 (only!)
Assigned To: dmitry
Previous Comments:
[2005-06-21 14:27:35] [EMAIL PROTECTED]
Fixed in CVS HEAD, PHP_5_0 and PHP_4_4.
[2005-06-18 04:10:37] [EMAIL PROTECTED]
That test seems to fail in HEAD now too..
[2005-06-14 09:31:44] [EMAIL PROTECTED]
I discussed this briefly with Dmitry - it's not an easy fix and
touching it creates other problems. We decided to suspend it until
we've more time to look at it.
[2005-01-19 22:11:51] [EMAIL PROTECTED]
See also bug #31217 and bug #30074
[2004-12-21 00:11:04] mikael at SPAMMENOTchl dot chalmers dot se
Description:
In regard to bug #29493 (would have added a comment to it if I could)
--
This fix seems to have been backported to PHP 4.3.9, now we get other
errors.
In the example below $acopy is a reference to $arr['acopy'] and $a is
also a reference to $arr['acopy'], when actually $a should have been
separated from $arr['acopy'] when extract() makes the $acopy reference
to $arr['acopy'] since the array is created with 'acopy' => $a
$b, $arr['bref'] and $bref should and does however all point to the
same value as they should since the array is created with 'bref' =>
&$b
Reproduce code:
Reproduce code:
---
$a = 1; $b = 1;
$arr = array('acopy' => $a, 'bref' => &$b);
extract($arr, EXTR_REFS);
$acopy++;
$bref++;
debug_zval_dump($a, $b, $arr, $acopy, $bref);
Expected result:
(As seen on PHP < 4.3.9):
$a: long(1) refcount(2)
$b: long(2) refcount(1)
$arr: array(2) refcount(2){
["acopy"]=>
&long(2) refcount(2)
["bref"]=>
&long(2) refcount(3)
}
$acopy: long(2) refcount(1)
$bref: long(2) refcount(1)
Note: Shouldn't the refcount of $a be == 1 instead of 2. $a should be a
separate zval while $arr['acopy'] and $acopy should be references to the
same value as indicated by the refcount of 2
Actual result:
--
$a is now == 2, when it should be == 1. Only $arr['acopy'] should be ==
2
$a: long(2) refcount(1)
$b: long(2) refcount(1)
$arr: array(2) refcount(2){
["acopy"]=>
&long(2) refcount(3)
["bref"]=>
&long(2) refcount(3)
}
$acopy: long(2) refcount(1)
$bref: long(2) refcount(1)
--
Edit this bug report at http://bugs.php.net/?id=31213&edit=1
#33389 [Csd->Opn]: double free() when exporting a ReflectionClass
ID: 33389
Updated by: [EMAIL PROTECTED]
Reported By: antony at zend dot com
-Status: Closed
+Status: Open
Bug Type: Zend Engine 2 problem
Operating System: *
PHP Version: 5CVS-2005-06-19
Assigned To: helly
New Comment:
The bug is not completly fixed.
1) It is still exists in PHP_5_0.
2) The test file in HEAD fails because constant is substituted by its
value.
3) Array argument give a memory leak
b)) {}
}
Reflection::export(new ReflectionClass('Test'));
?>
/home/dmitry/php/php5/Zend/zend.c(214) : Freeing 0x084384CC (6 bytes)
Previous Comments:
[2005-06-20 03:38:24] [EMAIL PROTECTED]
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.
[2005-06-18 03:08:31] [EMAIL PROTECTED]
constants are shown by their value, not name (expected?)
booleans are not shown at all.
[2005-06-18 02:00:53] [EMAIL PROTECTED]
This only happens when there is an optional parameter in a method and
ONLY if that optional value for the parameter is null or any constant.
[2005-06-18 00:32:49] antony at zend dot com
Description:
Memory related errors while freeing resources after export()ing certain
ReflectionClass object.
Tested with latest 5.1-CVS and 5.0.5-CVS.
See details below.
Reproduce code:
---
Expected result:
.
Actual result:
--
With Zend MM enabled:
Warning: String is not zero-terminated (Z*Z*) (source:
/usr/src/dev/php-src_head/Zend/zend_variables.h:35) in Unknown on line
0
[Sat Jun 18 02:20:58 2005] Script: 'index.php'
---
/usr/src/dev/php-src_head/Zend/zend_variables.h(35) : Block 0x0845EAE8
status:
/usr/src/dev/php-src_head/Zend/zend_variables.c(36) : Actual location
(location was relayed)
Beginning: Cached (allocated on
/usr/src/dev/php-src_head/Zend/zend.c:205, 1 bytes)
End: OK
---
With Zend MM disabled:
Warning: String is not zero-terminated ��@) (source:
/usr/src/dev/clean/php-src_head/Zend/zend_variables.h:35) in Unknown on
line 0
*** glibc detected *** double free or corruption (!prev): 0x08382470
***
Valgrind output:
==17469== Invalid read of size 1
==17469==at 0x81AC287: _zval_dtor_func (zend_variables.c:35)
==17469==by 0x81A5ED0: _zval_dtor (zend_variables.h:35)
==17469==by 0x81A58B4: destroy_op_array (zend_opcode.c:236)
==17469==by 0x81A54ED: destroy_zend_function (zend_opcode.c:109)
==17469==by 0x81A5503: zend_function_dtor (zend_opcode.c:121)
==17469==by 0x81B4FCB: zend_hash_destroy (zend_hash.c:519)
==17469==by 0x81A5628: destroy_zend_class (zend_opcode.c:164)
==17469==by 0x81B4F05: zend_hash_del_key_or_index
(zend_hash.c:490)
==17469==by 0x81B55C6: zend_hash_reverse_apply (zend_hash.c:736)
==17469==by 0x81A1828: shutdown_executor (zend_execute_API.c:264)
==17469== Address 0x1BDA99C5 is 5 bytes inside a block of size 6
free'd
==17469==at 0x1B9060B1: free (in
/usr/lib/valgrind/vgpreload_memcheck.so)
==17469==by 0x81A1DBD: zval_update_constant
(zend_execute_API.c:442)
==17469==by 0x81C76D9: _parameter_string
(zend_reflection_api.c:565)
==17469==by 0x81C7884: _function_parameter_string
(zend_reflection_api.c:601)
==17469==by 0x81C7B39: _function_string
(zend_reflection_api.c:670)
==17469==by 0x81C741D: _class_string (zend_reflection_api.c:486)
==17469==by 0x81CC8FF: zif_reflection_class___toString
(zend_reflection_api.c:2477)
==17469==by 0x81A31BE: zend_call_function (zend_execute_API.c:867)
==17469==by 0x81A2279: call_user_function_ex
(zend_execute_API.c:555)
==17469==by 0x81C8E62: zif_reflection_export
(zend_reflection_api.c:1127)
==17469==
==17469== Invalid free() / delete / delete[]
==17469==at 0x1B9060B1: free (in
/usr/lib/valgrind/vgpreload_memcheck.so)
==17469==by 0x81AC2BD: _zval_dtor_func (zend_variables.c:36)
==17469==by 0x81A5ED0: _zval_dtor (zend_variables.h:35)
==17469==by 0x81A58B4: destroy_op_array (zend_opcode.c:236)
==17469==by 0x81A54ED: destroy_zend_function (zend_opcode.c:109)
==17469==by 0x81A5503: zend_function_dtor (zend_opcode.c:121)
==17469==by 0x81B4FCB: zend_hash_destroy (zend_hash.c:519)
==17469==by 0x81A5628: destroy_zend_class (zend_opcode.c:164)
==17469==by 0x81B4F05: zend_hash_del_key_or_index
(zend_hash.c:490)
==17469==by 0x81B55C6: zend_hash_reverse_apply (zend_hash.c:736)
==17469== Address 0x1BDA99C0 is 0 by
#33257 [Asn->Csd]: array_splice() inconsistent when passed function instead of variable
ID: 33257 Updated by: [EMAIL PROTECTED] Reported By: jacob at jacobweber dot com -Status: Assigned +Status: Closed Bug Type: Class/Object related Operating System: * PHP Version: 5CVS-2005-06-19 Assigned To: dmitry New Comment: Fixed in CVS HEAD and PHP_5_0. Previous Comments: [2005-06-19 02:04:35] [EMAIL PROTECTED] This is pretty magical thing. Dmitry, can you check this out? [2005-06-06 17:24:57] jacob at jacobweber dot com Description: array_splice expects an array reference for its first argument. But sometimes you can pass it a function that doesn't return an array reference, and it will work. The function has to be a static method inside a class, and it has to return a static variable of that class. In this case, array_splice will actually update the class's variable, which it shouldn't be able to do. Even stranger, this behavior won't happen if you've assigned another variable to the result of that function. In the example below, you only get the error message when you uncomment line 8. As far as I can tell, that should have no effect. Reproduce code: --- Expected result: Fatal error: Only variables can be passed by reference in test.php on line 9 Actual result: -- Array ( [0] => a [1] => c ) -- Edit this bug report at http://bugs.php.net/?id=33257&edit=1
#29896 [Ver->Csd]: Backtrace argument list out of sync
ID: 29896
Updated by: [EMAIL PROTECTED]
Reported By: terry at pothecary dot com
-Status: Verified
+Status: Closed
Bug Type: Zend Engine 2 problem
Operating System: *
PHP Version: 5CVS-2005-06-19
New Comment:
Fixed in CVS HEAD and PHP_5_0.
Previous Comments:
[2004-08-30 14:14:39] terry at pothecary dot com
Description:
If you call and enumerate the information from a debug_backtrace() in a
user error handler then the argument list is out of step with the other
information.
Reproduce code:
---
function userErrorHandler($num, $msg, $file, $line, $vars)
{
debug_print_backtrace();
}
$OldErrorHandler = set_error_handler("userErrorHandler");
function GenerateError1($A1)
{
$a = $b;
}
function GenerateError2($A1)
{
GenerateError1("Test1");
}
GenerateError2("Test2");
Expected result:
I expect the final line in the backtrace to show a call of:
GenerateError2(Test2)
Actual result:
--
The final line in the backtrace shows a call of:
GenerateError2(Test1)
--
Edit this bug report at http://bugs.php.net/?id=29896&edit=1
#27268 [Asn->Opn]: Bad references accentuated by clone
ID: 27268
Updated by: [EMAIL PROTECTED]
Reported By: lingwitt at bellsouth dot net
-Status: Assigned
+Status: Open
Bug Type: Zend Engine 2 problem
Operating System: *
PHP Version: 5CVS-2005-06-19
Assigned To: dmitry
New Comment:
Fixed in cvs HEAD (not in PHP_5_0).
The simular patch
(http://cvs.php.net/diff.php/ZendEngine2/zend_execute.c?r1=1.707&r2=1.708&ty=u)
probably can be applyed to PHP_5_0 too.
Previous Comments:
[2005-06-19 21:18:52] [EMAIL PROTECTED]
Still happens..
[2005-05-25 12:32:37] ericvanblokland at gmail dot com
Isn't this related to
http://bugs.php.net/bug.php?id=24485
when copies become references? (Clone should copy variables from an
object, but because of the bug mentioned above, variables can no longer
be copied, just referenced)
[2004-02-15 23:47:13] lingwitt at bellsouth dot net
In fact, the reference doesn't need to be made in a
method:
class A
{
var $a = array();
public function &getA()
{
return $this->a;
}
}
$A = new A;
$A->a = array(1);
$array = $A->getA();
$clone = clone $A;
$clone->a = array();
print_r($A);
[2004-02-15 21:06:03] lingwitt at bellsouth dot net
Description:
When an object's method calls upon another one of its
methods such that the second method returns a reference
that is stored in the the first method as a local
variable, then the reference persists in some way so as
to make cloning problematic.
As a result, a modification to the referenced variable
in the clone cuases a modification to the same variable
in original.
Reproduce code:
---
class A
{
var $a = array();
public function makeAReference()
{
$array = $this->getA();
}
public function &getA()
{
return $this->a;
}
}
$A = new A;
$A->a = array(1);
$A->makeAReference();
$clone = clone $A;
$clone->a = array();
print_r($A);
Expected result:
This is gotten when $A->makeAReference() is removed.
A Object
(
[a] => Array
(
[0] => 1
)
)
Actual result:
--
Obviously the modification made it back to the original.
A Object
(
[a] => Array
(
)
)
--
Edit this bug report at http://bugs.php.net/?id=27268&edit=1
#28054 [Asn->Csd]: debug_backtrace() bug
ID: 28054
Updated by: [EMAIL PROTECTED]
Reported By: misu200 at yahoo dot com
-Status: Assigned
+Status: Closed
Bug Type: Zend Engine 2 problem
Operating System: *
PHP Version: 5CVS-2005-06-19
Assigned To: andi
New Comment:
Fixed in CVS HEAD and PHP_5_0.
Arguments to ourErrorHandler() are shown.
Argument to require_once() are not shown in case of error, because
require_once() is internal function and its argument cannot be
restored.
Previous Comments:
[2005-05-17 14:29:06] [EMAIL PROTECTED]
The problem here is that error handler call does not provide necessary
information for recovering the arguments. This is because include does
not preserve the argument and backtrace bases on the fact that code
executed after include() is necessarily the included file - which is
not the case if include fails, of course.
[2004-04-19 20:12:47] [EMAIL PROTECTED]
Assigning to the engine guru, Andi.
[2004-04-19 16:45:48] olivier dot bichler at laposte dot net
And there is an other problem : why the arguments $errNo, $errStr,
$errFile, $errLine are not present in the result of debug_backtrace()
?
I have the same problem...
[2004-04-19 09:05:28] misu200 at yahoo dot com
Description:
I set my own error handle function and then i try to include a
non-existent file (aga.php).The problem is when i make a
var_dump(debug_backtrace()) in my error handle function it shows me
wrong results.
Reproduce code:
---
";
var_dump(debug_backtrace());
echo "";
}
// set the user error handler to be the above
$oldErrorHandler = set_error_handler("ourErrorHandler",
error_reporting());
require_once("aga.php");
?>
Expected result:
array(2) {
[0]=>
array(3) {
["file"]=>
string(28) "/var/www/html/dir1/file2.php"
["line"]=>
int(15)
["function"]=>
string(15) "ourErrorHandler"
}
[1]=>
array(4) {
["file"]=>
string(28) "/var/www/html/dir1/file2.php"
["line"]=>
int(15)
["args"]=>
array(1) {
[0]=>
string(28) "aga.php" < - this should be here
}
["function"]=>
string(12) "require_once"
}
}
Actual result:
--
array(2) {
[0]=>
array(3) {
["file"]=>
string(28) "/var/www/html/dir1/file2.php"
["line"]=>
int(15)
["function"]=>
string(15) "ourErrorHandler"
}
[1]=>
array(4) {
["file"]=>
string(28) "/var/www/html/dir1/file2.php"
["line"]=>
int(15)
["args"]=>
array(1) {
[0]=>
string(28) "/var/www/html/dir1/file2.php" <- is wrong
}
["function"]=>
string(12) "require_once"
}
}
--
Edit this bug report at http://bugs.php.net/?id=28054&edit=1
#31177 [Ver->Asn]: Memory leak
ID: 31177
Updated by: [EMAIL PROTECTED]
Reported By: guth at fiifo dot u-psud dot fr
-Status: Verified
+Status: Assigned
Bug Type: Zend Engine 2 problem
Operating System: *
PHP Version: 5CVS-2005-06-19
-Assigned To:
+Assigned To: dmitry
Previous Comments:
[2005-03-29 00:49:16] [EMAIL PROTECTED]
/usr/src/php/php5/Zend/zend_vm_execute.h(370) : Freeing 0x08FBAECC (16
bytes), script=t.php
=== Total 1 memory leaks detected ===
[2005-01-07 18:56:57] [EMAIL PROTECTED]
/usr/src/web/php/php5/Zend/zend_vm_execute.h(350) : Freeing 0x0880A664
(16 bytes)
[2004-12-18 10:41:02] guth at fiifo dot u-psud dot fr
Description:
The following code produces a memory leak :
/usr/src/php-5.0.3RC1/Zend/zend_execute.c(3255) : Freeing 0x0816FB6C
(16 bytes), script=/www/test3.php
=== Total 1 memory leaks detected ===
Reproduce code:
---
query());
}
}
class DbGowRecordSet {
public function __construct($resource) {
}
}
$db = new DbGow;
try {
$rs = $db->select();
}
catch(Exception $e) {
}
?>
--
Edit this bug report at http://bugs.php.net/?id=31177&edit=1
#30828 [Ver->Csd]: debug_backtrace() reports incorrect class in overridden methods
ID: 30828
Updated by: [EMAIL PROTECTED]
Reported By: lists at infospleen dot com
-Status: Verified
+Status: Closed
Bug Type: Zend Engine 2 problem
Operating System: *
PHP Version: 5CVS-2005-06-19
-Assigned To:
+Assigned To: dmitry
New Comment:
Fixed in CVS HEAD and PHP_5_0.
Previous Comments:
[2005-01-07 13:39:43] vargusz at freemail dot hu
Possibly the same underlying code causes inherited static method calls
to be misreported:
class A {
static function f () {
$bt = debug_backtrace();
echo "{$bt['class']}\n";
}
}
class B extends A {}
And both A::f() and B::f() produce 'A'.
[2004-11-18 16:32:47] lists at infospleen dot com
Description:
If class B extends class A, and overrides a method of class A,
debug_backtrace() reports that the method of class A is a method of
class B instead.
Reproduce code:
---
class A {
function __construct() {
$bt = debug_backtrace();
foreach ($bt as $t)
print
$t['class'].'::'.
$t['function'].'';
}
}
class B extends A {
function __construct() {
parent::__construct();
}
}
$b = new B();
Expected result:
Expected output:
A::__construct
B::__construct
Actual result:
--
Actual output:
B::__construct
B::__construct
--
Edit this bug report at http://bugs.php.net/?id=30828&edit=1
#32660 [Asn->Csd]: Assignment by reference causes crash when field access is overloaded (__get)
ID: 32660
Updated by: [EMAIL PROTECTED]
Reported By: ladislav dot prosek at matfyz dot cz
-Status: Assigned
+Status: Closed
Bug Type: Zend Engine 2 problem
Operating System: *
PHP Version: 5CVS-2005-06-19
Assigned To: dmitry
New Comment:
Fixed in CVS HEAD and PHP_5_0.
Previous Comments:
[2005-06-20 10:50:37] [EMAIL PROTECTED]
Dmitry, plz take a look into it, it's still valid for HEAD.
[2005-05-11 12:40:55] [EMAIL PROTECTED]
Initializing $a->whatever before assigning reference can be used as a
temporary workaround.
[2005-04-11 02:04:49] [EMAIL PROTECTED]
object(A)#1 (1) {
["q"]=>
&UNKNOWN:0
}
/usr/src/php/php5/Zend/zend_execute.c(891) : Freeing 0x0A117D6C (16
bytes), script=/home/jani/t.php
/usr/src/php/php5/Zend/zend_variables.h(45) : Freeing 0x0A117D2C (12
bytes), script=/home/jani/t.php
/usr/src/php/php5/Zend/zend_variables.c(120) : Actual location
(location was relayed)
=== Total 2 memory leaks detected ===
[2005-04-10 22:22:04] ladislav dot prosek at matfyz dot cz
Description:
There is probably a bug in memory allocation related to property
getters. Note that the behavior depends on lengths of the two strings
and also on the way the $q property is initialized.
Reproduce code:
---
class A
{
var $q;
function __construct()
{
$this->q = array();
}
function __get($name)
{
return $this->q;
}
};
$a = new A;
$b = "short";
$a->whatever =& $b;
$b = "much longer";
var_dump($a);
Expected result:
// as __get does not return a reference
// the output should IMHO look like this:
object(A)#1 (1) {
["q"]=>
array(0) {
}
}
// if you guys think the output should be
// different, please do explain it!
Actual result:
--
object(A)#1 (1) {
["q"]=>
CRASH!
--
Edit this bug report at http://bugs.php.net/?id=32660&edit=1
#28377 [Ver->Csd]: debug_backtrace is intermittently passing args
ID: 28377 Updated by: [EMAIL PROTECTED] Reported By: sean at caedmon dot net -Status: Verified +Status: Closed Bug Type: Scripting Engine problem Operating System: * PHP Version: 5CVS, 4CVS (2005-06-19) -Assigned To: +Assigned To: dmitry New Comment: Fixed in CVS HEAD, PHP_5_0 and PHP_4_4. Previous Comments: [2005-03-15 11:45:07] [EMAIL PROTECTED] debug_backtrace loses information in subsequent movements up the stack. Simple test script: This block should be present in both backtraces: [function] => c [args] => Array ( [0] => foo [1] => bar ) In the second backtrace, it is not: [function] => c [args] => Array ( ) This problem does not, as one might expect, propogate to debug_print_backtrace. [2004-05-12 20:43:48] sean at caedmon dot net Description: debug_backtrace() behaves strangely when passed as a function argument. This does not happen if debug_backtrace is dereferenced (see code), nor if debug_backtrace() is the first parameter to my custom_callback function (not denoted in code) I'll be happy to provide additional details. This SEEMS like #27397 but is not a ZE2 problem (I'm using 4.3) and is NOT fixed in CVS. Thanks, S Reproduce code: --- Expected result: dereferenced -- args: exists direct -- args: exists Actual result: -- dereferenced -- args: exists direct -- args: does not exist -- Edit this bug report at http://bugs.php.net/?id=28377&edit=1
#30519 [Ver->Csd]: Interface not existing says Class not found
ID: 30519 Updated by: [EMAIL PROTECTED] Reported By: jsgoupil at lookstrike dot com -Status: Verified +Status: Closed Bug Type: Scripting Engine problem Operating System: * PHP Version: 5CVS-2005-06-19 -Assigned To: +Assigned To: dmitry New Comment: Fixed in CVS HEAD and PHP_5_0. Previous Comments: [2004-10-21 20:48:56] jsgoupil at lookstrike dot com Description: If you specify an interface that not exists to a class, the output error is saying a "wrong" message... Reproduce code: --- Expected result: Fatal error: Interface 'a' not found in D:\www\LookStrike\ls_lite\a.php on line 2 Actual result: -- Fatal error: Class 'a' not found in D:\www\LookStrike\ls_lite\a.php on line 2 -- Edit this bug report at http://bugs.php.net/?id=30519&edit=1
#26584 [Ver->Asn]: Class member - array key overflow
ID: 26584 Updated by: [EMAIL PROTECTED] Reported By: [EMAIL PROTECTED] -Status: Verified +Status: Assigned Bug Type: Scripting Engine problem Operating System: * PHP Version: 5CVS, 4CVS (2005-06-19) -Assigned To: +Assigned To: dmitry New Comment: The bug is partially fixed in CVS HEAD, PHP_5_0 and PHP_4_4. Integer overflow problem is not solved, but now constant arrays can use null, boolean and double indecies. Previous Comments: [2005-06-19 21:22:56] [EMAIL PROTECTED] See also bug #28972 Still fails and leaks. [2005-01-25 15:41:04] [EMAIL PROTECTED] Leaks too: php5/Zend/zend_compile.c(3005) : Freeing 0x082268CC (16 bytes) php5/Zend/zend_language_scanner.l(1607) : Freeing 0x08226894 (5 bytes) php_4_3/Zend/zend_compile.c(1872) : Freeing 0x086549D4 (12 bytes) php_4_3/Zend/zend_language_scanner.l(1531) : Freeing 0x0865499C (5 bytes) [2003-12-10 10:04:35] [EMAIL PROTECTED] Description: See attached code. It seems that when assigning arrays in a class definition, it's possible to overflow the array key, without any sort of warning/notice/etc. This only happens in a class def, and not to a "global" namespace array. It's odd that the same code isn't used for both regular array constructs, and object array constructs (Zend Engine). ZE2 may fix this problem. Has not been tested. The logical overflow threshold is between 2147483647 and 2147483648 (where 2147483648 is a 32bit (singed) integer value of -0, if I'm not mistaken -- or 0x8000). Note: this affects more than just negative keys as seen in code:VAL3. I don't have time to jump into the php source right now (nor am I truly qualified to do so). Please let me know if/when you need additional details. S ([EMAIL PROTECTED]) Reproduce code: --- http://sean.caedmon.net/php/class_array_bug.phps (http://sean.caedmon.net/php/class_array_bug.php) Expected result: (see code) Actual result: -- (see code) -- Edit this bug report at http://bugs.php.net/?id=26584&edit=1
#28072 [Ver->Asn]: static array with some constant keys will be incorrectly ordered
ID: 28072 Updated by: [EMAIL PROTECTED] Reported By: pages at inrp dot fr -Status: Verified +Status: Assigned Bug Type: Scripting Engine problem Operating System: * PHP Version: 5CVS, 4CVS (2005-06-19) -Assigned To: +Assigned To: dmitry Previous Comments: [2004-04-20 07:54:00] pages at inrp dot fr Description: Initialising a static associative array using constants as keys will give an incorrectly ordered array. Apparently, elements with constant keys will always appear AFTER elements without constant keys. Reproduce code: --- "111", "b" => "222", THIRD_KEY => "333", "d" => "444" ); print_r($arr); } test(); ?> Expected result: Array ( [a] => 111 [b] => 222 [c] => 333 [d] => 444 ) Actual result: -- Array ( [b] => 222 [d] => 444 [a] => 111 [c] => 333 ) -- Edit this bug report at http://bugs.php.net/?id=28072&edit=1
#33487 [Asn]: Memory allocated for objects created in object methods is not released
ID: 33487 Updated by: [EMAIL PROTECTED] Reported By: robert dot munteanu at betbrain dot com Status: Assigned Bug Type: Scripting Engine problem Operating System: * PHP Version: 5CVS-2005-06-27 Assigned To: dmitry New Comment: This is not really a bug, but unefficient usage of memory by zend_object_storage. It frees object buckets only on request shutdown. The test case allocates: 16384 * sizeof(zend_object_store_bucket) = 393216 bytes Previous Comments: [2005-06-27 12:17:20] [EMAIL PROTECTED] Dmitry, is there any way to fix this..? (btw. unset() does NOT free all the memory..but that's, AFAIK, by design) [2005-06-27 11:31:02] robert dot munteanu at betbrain dot com Description: Whenever you create an object in a method, memory is not released when the method execution ends, unset() must be called manually. This becomes a problem when you have long-running scripts, which perform actions repeatedly which leads to the script running out of memory. Reproduce code: --- doNothing(); echo "After: ".memory_get_usage()."\n"; ?> Expected result: Memory usage remains roughly the same. Actual result: -- Before: 41424 After: 432560 -- Edit this bug report at http://bugs.php.net/?id=33487&edit=1
#32852 [Asn->Fbk]: Crash with singleton and __destruct when zend.ze1_compatibility_mode = On
ID: 32852 Updated by: [EMAIL PROTECTED] Reported By: cox at idecnet dot com -Status: Assigned +Status: Feedback Bug Type: Scripting Engine problem Operating System: * PHP Version: 5CVS-2005-04-29 Assigned To: dmitry New Comment: I assume this is xdebug bug. I don't see any problems without it. Previous Comments: [2005-07-01 11:42:49] [EMAIL PROTECTED] Now I get this crash with Zend/tests/bug32852.phpt: (gdb) bt #0 add_stack_frame (zdata=0xbfff8440, op_array=0x99d121c, type=1) at /usr/src/xdebug-cvs/xdebug.c:885 #1 0x00f805bd in xdebug_execute (op_array=0x99d121c) at /usr/src/xdebug-cvs/xdebug.c:1123 #2 0x0818a75a in zend_call_function (fci=0xbfff8540, fci_cache=0xbfff8500) at /usr/src/php5/Zend/zend_execute_API.c:855 #3 0x081a6c40 in zend_call_method (object_pp=0xbfff85ec, obj_ce=0x99d0874, fn_proxy=0x99d094c, function_name=0x825a5bb "__destruct", function_name_len=10, retval_ptr_ptr=0x0, param_count=0, arg1=0x0, arg2=0x0) at /usr/src/php5/Zend/zend_interfaces.c:87 #4 0x081abc4f in zend_objects_destroy_object (object=0x99d004c, handle=1) at /usr/src/php5/Zend/zend_objects.c:78 #5 0x081ae6d8 in zend_objects_store_del_ref (zobject=0x99d000c) at /usr/src/php5/Zend/zend_objects_API.c:155 #6 0x08193dd8 in _zval_dtor_func (zvalue=0x99d000c, __zend_filename=0x8257204 "/usr/src/php5/Zend/zend_variables.h", __zend_lineno=35) at /usr/src/php5/Zend/zend_variables.c:52 #7 0x08188d11 in _zval_dtor (zvalue=0x99d000c, __zend_filename=0x82571b0 "/usr/src/php5/Zend/zend_execute_API.c", __zend_lineno=386) at zend_variables.h:35 #8 0x08188ec4 in _zval_ptr_dtor (zval_ptr=0xbfff875c, __zend_filename=0x825bf80 "/usr/src/php5/Zend/zend_vm_execute.h", __zend_lineno=222) at /usr/src/php5/Zend/zend_execute_API.c:386 #9 0x081bbbe2 in zend_do_fcall_common_helper_SPEC (execute_data=0xbfff8780) at zend_vm_execute.h:222 #10 0x081bc223 in ZEND_DO_FCALL_BY_NAME_SPEC_HANDLER (execute_data=0xbfff8780) at zend_vm_execute.h:299 #11 0x081bb69b in execute (op_array=0x99cb15c) at zend_vm_execute.h:87 #12 0x00f8072c in xdebug_execute (op_array=0x99cb15c) at /usr/src/xdebug-cvs/xdebug.c:1158 #13 0x08195c59 in zend_execute_scripts (type=8, retval=0x0, file_count=3) at /usr/src/php5/Zend/zend.c:1087 #14 0x0815512b in php_execute_script (primary_file=0xbfffac10) at /usr/src/php5/main/main.c:1671 #15 0x08200287 in main (argc=4, argv=0xbffface4) at /usr/src/php5/sapi/cli/php_cli.c:1039 [2005-04-29 09:05:00] [EMAIL PROTECTED] Fixed in CVS HEAD and PHP_5_0. ---- [2005-04-29 03:29:29] [EMAIL PROTECTED] Dmitry, if you have time, can you look into these reports with problems with zend.ze1_compatibility_mode? Some of them happen with only PHP_5_0 and some with both it and HEAD. Here's list (this bug excluded): bug #30332 bug #31828 bug #32080 [2005-04-28 16:03:57] cox at idecnet dot com Not using my php.ini doesn't crash in 5.0.4, 5.0.5dev or 5.1cvs and the output match the expected. So investigating my modified settings from the original php.ini-dist, I've found that ze1_compat generates the problem: zend.ze1_compatibility_mode = On (turning it Off does not crash, well, afterall it's php5 only syntax). The other requested data: gcc-3.4.1 bison-1.875 glibc-2.3.3 [2005-04-28 13:52:55] [EMAIL PROTECTED] I still can't reproduce this. I get same result with both HEAD and PHP_5_0 branches and also with the snapshot. Does it give same result if you make sure you don't load any php.ini: sapi/cli/php -n file.php What bison version do you have installed? What compiler (and version) ? The remainder of the comments for this report are too long. To view the rest of the comments, please view the bug report online at http://bugs.php.net/32852 -- Edit this bug report at http://bugs.php.net/?id=32852&edit=1
#33512 [Opn]: Encountered error on using magic method (Overload Section)
ID: 33512
Updated by: [EMAIL PROTECTED]
Reported By: muhamad_zakaria at yahoo dot com
Status: Open
Bug Type: Scripting Engine problem
Operating System: Windows XP Pro
PHP Version: 5.1.0-dev
New Comment:
PHP hasn't magic callback to unset overloaded properties.
This is the reason why unset($SomeObj->Virtual1) doesn't work.
Previous Comments:
[2005-07-04 10:38:12] muhamad_zakaria at yahoo dot com
We have tried from the feedback (tony2001), and the raised error is no
longer.
But we have another experiences while using 'unset' statement, such as
below:
// we will try to unset these variables
unset($SomeObj->RealVar1);
unset($SomeObj->{'RealVar'.(3)});
//the lines below will catch by '__get' magic method since these
variables are unavailable anymore
print $SomeObj->RealVar1."\n";
print $SomeObj->{'RealVar'.(3)}."\n";
// now we will try to unset these variables
unset($SomeObj->Virtual1);
unset($SomeObj->{'Virtual'.(3)});
//but, these variables are still available??? eventhough they're
"unset"-ed
print $SomeObj->Virtual1."\n";
print $SomeObj->{'Virtual'.(3)}."\n";
[2005-06-30 10:23:37] [EMAIL PROTECTED]
Please try using this CVS snapshot:
http://snaps.php.net/php5-latest.tar.gz
For Windows:
http://snaps.php.net/win32/php5-win32-latest.zip
[2005-06-30 05:12:01] muhamad_zakaria at yahoo dot com
Description:
When we used virtual variables exploiting __set overload method, we
encountered errors.
Reproduce code:
---
class TheObj {
public $RealVar1, $RealVar2, $RealVar3, $RealVar4;
public $Var = array();
function __set($var, $val) {
$this->Var[$var] = $val;
}
function __get($var) {
if(isset($this->Var[$var])) return $this->Var[$var];
else return -1;
}
}
$SomeObj = new TheObj;
// this will fine
$SomeObj->RealVar1 = 'somevalue';
$SomeObj->{'RealVar2'} = 'othervalue';
$SomeObj->{'RealVar'.(3)} = 'othervaluetoo';
$SomeObj->{'RealVar'.'4'} = 'anothervalue';
// this will fine too
$SomeObj->Virtual1 = 'somevalue';
$SomeObj->{'Virtual2'} = 'othervalue';
// it's can't be used since this will encounter error
$SomeObj->{'Virtual'.(3)} = 'othervaluetoo';
$SomeObj->{'Virtual'.'4'} = 'anothervalue';
// but this will fine, ofcourse
$SomeObj->Var['Virtual'.(3)] = 'othervaluetoo';
$SomeObj->Var['Virtual'.'4'] = 'anothervalue';
Expected result:
No error when we use below lines:
{'Virtual'.(3)} = 'othervaluetoo';
$SomeObj->{'Virtual'.'4'} = 'anothervalue';
?>
because this should applied fine as we did at "RealVarX" treatments.
Actual result:
--
Encountered error raises by php.exe
--
Edit this bug report at http://bugs.php.net/?id=33512&edit=1
#31158 [Ver->Csd]: array_splice on $GLOBALS crashes
ID: 31158
Updated by: [EMAIL PROTECTED]
Reported By: postings-php-bug at hans-spath dot de
-Status: Verified
+Status: Closed
Bug Type: Reproducible crash
Operating System: *
PHP Version: 5CVS, 4CVS (2005-02-21)
-Assigned To:
+Assigned To: dmitry
New Comment:
Fixed in CVS HEAD and PHP_5_0.
Previous Comments:
[2004-12-18 17:31:41] postings-php-bug at hans-spath dot de
<0>[EMAIL PROTECTED]:~/compile/php-4.3.10/sapi/cli% cat ~/test/killer.php
[EMAIL PROTECTED]:~/compile/php-4.3.10/sapi/cli% gdb php
[...]
This GDB was configured as "i386-linux"...Using host libthread_db
library "/lib/libthread_db.so.1".
(gdb) run ~/test/killer.php
Starting program: /home/stob/compile/php-4.3.10/sapi/cli/php
~/test/killer.php
[Sat Dec 18 17:28:35 2004] Script: '/home/stob/test/killer.php'
---
/home/stob/compile/php-4.3.10/ext/standard/array.c(1897) : Block
0x081C2B28 status:
Beginning: Overrun (magic=0x, expected=0x7312F8DC)
Program received signal SIGSEGV, Segmentation fault.
0xb7ec81c3 in memcpy () from /lib/libc.so.6
(gdb) bt
#0 0xb7ec81c3 in memcpy () from /lib/libc.so.6
#1 0x0814ace4 in _mem_block_check (ptr=0x81c2b4c, silent=0,
__zend_filename=0x817ef80
"/home/stob/compile/php-4.3.10/ext/standard/array.c",
__zend_lineno=1897, __zend_orig_filename=0x0, __zend_orig_lineno=0)
at /home/stob/compile/php-4.3.10/Zend/zend_alloc.c:675
#2 0x0814aca5 in _mem_block_check (ptr=0x81c2b4c, silent=1,
__zend_filename=0x817ef80
"/home/stob/compile/php-4.3.10/ext/standard/array.c",
__zend_lineno=1897, __zend_orig_filename=0x0, __zend_orig_lineno=0)
at /home/stob/compile/php-4.3.10/Zend/zend_alloc.c:667
#3 0x08149feb in _efree (ptr=0x81c2b4c, __zend_filename=0x817ef80
"/home/stob/compile/php-4.3.10/ext/standard/array.c",
__zend_lineno=1897,
__zend_orig_filename=0x0, __zend_orig_lineno=0) at
/home/stob/compile/php-4.3.10/Zend/zend_alloc.c:243
#4 0x080a2b90 in zif_array_splice (ht=3, return_value=0x81f6af4,
this_ptr=0x0, return_value_used=0)
at /home/stob/compile/php-4.3.10/ext/standard/array.c:1897
#5 0x0816eeb3 in execute (op_array=0x81f69b8) at
/home/stob/compile/php-4.3.10/Zend/zend_execute.c:1642
#6 0x0816f0b1 in execute (op_array=0x81f15bc) at
/home/stob/compile/php-4.3.10/Zend/zend_execute.c:1686
#7 0x0815be29 in zend_execute_scripts (type=8, retval=0x0,
file_count=3) at /home/stob/compile/php-4.3.10/Zend/zend.c:900
#8 0x08127f54 in php_execute_script (primary_file=0xba60) at
/home/stob/compile/php-4.3.10/main/main.c:1736
#9 0x0817507b in main (argc=2, argv=0xbae4) at
/home/stob/compile/php-4.3.10/sapi/cli/php_cli.c:822
[2004-12-17 20:41:04] postings-php-bug at hans-spath dot de
Description:
PHP doesn't handle an attempt of clearing $GLOBALS correctly.
Reproduce code:
---
function __(){array_splice($GLOBALS,0,count($GLOBALS));}__();
Expected result:
$GLOBALS should be empty or an error message should be printed.
Actual result:
--
My tests:
PHP 4.3.8 cli/cgi, 4.3.10 cli, Linux 2.6:
segmentation fault
PHP 4.3.8 apache2sapi, Windows XP SP2:
Apache2 log: Parent: child process exited with status 3221225477 --
Restarting.
PHP 5.0.1 cli, Windows XP SP2:
array_splice works, but then crashes on script end (probably during
cleanups) or on phpinfo();
--
Edit this bug report at http://bugs.php.net/?id=31158&edit=1
#33520 [Opn->Csd]: crash if safe_mode is on and session.save_path is changed
ID: 33520 Updated by: [EMAIL PROTECTED] Reported By: dexter at debian dot org -Status: Open +Status: Closed Bug Type: Reproducible crash Operating System: Debian PHP Version: 5CVS-2005-06-30 (dev) -Assigned To: +Assigned To: dmitry New Comment: Fixed in CVS HEAD and PHP_5_0. Previous Comments: [2005-07-01 14:04:58] dexter at debian dot org The latest CVS snapshot: Script started on Fri 01 Jul 2005 02:02:34 PM CEST test-server01:~# gdb /usr/sbin/apache2 /tmp/core GNU gdb 6.3-debian Copyright 2004 Free Software Foundation, Inc. GDB is free software, covered by the GNU General Public License, and you are welcome to change it and/or distribute copies of it under certain conditions. Type "show copying" to see the conditions. There is absolutely no warranty for GDB. Type "show warranty" for details. This GDB was configured as "i386-linux"...(no debugging symbols found) Using host libthread_db library "/lib/tls/libthread_db.so.1". (no debugging symbols found) Core was generated by `/usr/sbin/apache2 -k start -DSSL'. Program terminated with signal 11, Segmentation fault. warning: current_sos: Can't read pathname for load map: Input/output error Reading symbols from /lib/tls/libcrypt.so.1...(no debugging symbols found)...done. Loaded symbols for /lib/tls/libcrypt.so.1 Reading symbols from /usr/lib/libpcre.so.3...(no debugging symbols found)...done. Loaded symbols for /usr/lib/libpcre.so.3 Reading symbols from /usr/lib/libz.so.1... (no debugging symbols found)...done. Loaded symbols for /usr/lib/libz.so.1 Reading symbols from /usr/lib/i686/cmov/libssl.so.0.9.7... (no debugging symbols found)...done. Loaded symbols for /usr/lib/i686/cmov/libssl.so.0.9.7 Reading symbols from /usr/lib/i686/cmov/libcrypto.so.0.9.7... (no debugging symbols found)...done. Loaded symbols for /usr/lib/i686/cmov/libcrypto.so.0.9.7 Reading symbols from /lib/tls/libdl.so.2...(no debugging symbols found)...done. Loaded symbols for /lib/tls/libdl.so.2 Reading symbols from /usr/lib/libaprutil-0.so.0... (no debugging symbols found)...done. Loaded symbols for /usr/lib/libaprutil-0.so.0 Reading symbols from /usr/lib/libldap.so.2...(no debugging symbols found)...done. Loaded symbols for /usr/lib/libldap.so.2 Reading symbols from /usr/lib/liblber.so.2... (no debugging symbols found)...done. Loaded symbols for /usr/lib/liblber.so.2 Reading symbols from /usr/lib/libdb-4.2.so...(no debugging symbols found)...done. Loaded symbols for /usr/lib/libdb-4.2.so Reading symbols from /usr/lib/libexpat.so.1... (no debugging symbols found)...done. Loaded symbols for /usr/lib/libexpat.so.1 Reading symbols from /usr/lib/libapr-0.so.0...(no debugging symbols found)...done. Loaded symbols for /usr/lib/libapr-0.so.0 Reading symbols from /lib/tls/librt.so.1... (no debugging symbols found)...done. Loaded symbols for /lib/tls/librt.so.1 Reading symbols from /lib/tls/libm.so.6...(no debugging symbols found)...done. Loaded symbols for /lib/tls/libm.so.6 Reading symbols from /lib/tls/libnsl.so.1... (no debugging symbols found)...done. Loaded symbols for /lib/tls/libnsl.so.1 Reading symbols from /lib/tls/libpthread.so.0...(no debugging symbols found)...done. Loaded symbols for /lib/tls/libpthread.so.0 Reading symbols from /lib/tls/libc.so.6... (no debugging symbols found)...done. Loaded symbols for /lib/tls/libc.so.6 Reading symbols from /lib/ld-linux.so.2...(no debugging symbols found)...done. Loaded symbols for /lib/ld-linux.so.2 Reading symbols from /lib/tls/libresolv.so.2... (no debugging symbols found)...done. Loaded symbols for /lib/tls/libresolv.so.2 Reading symbols from /usr/lib/libsasl2.so.2...(no debugging symbols found)...done. Loaded symbols for /usr/lib/libsasl2.so.2 Reading symbols from /usr/lib/libgnutls.so.11... (no debugging symbols found)...done. Loaded symbols for /usr/lib/libgnutls.so.11 Reading symbols from /usr/lib/libtasn1.so.2...(no debugging symbols found)...done. Loaded symbols for /usr/lib/libtasn1.so.2 Reading symbols from /usr/lib/libgcrypt.so.11... (no debugging symbols found)...done. Loaded symbols for /usr/lib/libgcrypt.so.11 Reading symbols from /usr/lib/libgpg-error.so.0...(no debugging symbols found)...done. Loaded symbols for /usr/lib/libgpg-error.so.0 Reading symbols from /lib/tls/libnss_compat.so.2... (no debugging symbols found)...done. Loaded symbols for /lib/tls/libnss_compat.so.2 Reading symbols from /lib/tls/libnss_nis.so.2...(no debugging symbols found)...done. Loaded symbols for /lib/tls/libnss_nis.so.2 Reading symbols from /lib/tls/libnss_files.so.2... ---Type to continue, or q to quit--- (no debugging symbols found)...done. Loaded symbols for /lib/tls/libnss_files.so.2 Reading symbols from /usr/lib/apache2/mod
#33567 [Asn->Fbk]: SoapClient Only Works If Exceptions Turned Off
ID: 33567
Updated by: [EMAIL PROTECTED]
Reported By: please-no-spam at blueyonder dot co dot uk
-Status: Assigned
+Status: Feedback
Bug Type: SOAP related
Operating System: Windows XP Pro
PHP Version: 5.1.0b2
Assigned To: dmitry
New Comment:
I cannot reproduce this bug, but may be this is IIS6 specific problem.
Could you please add "trace" option to SoapClient constructor and the
following code after soap call.
var_dump($x->__getLastResponseHeaders());
var_dump($x->__getLastResponse());
Previous Comments:
[2005-07-04 21:58:52] [EMAIL PROTECTED]
Assigned to the maintainer.
[2005-07-04 19:52:34] please-no-spam at blueyonder dot co dot uk
Description:
When I try to create my own web service using php 5.0.3 or 5.1.0b2
using Dmitry Stogov's example at zend.com code on Windows XP Pro IIS6:
eg:
$x = SoapClient(WSDL);
I get:
SoapFault exception: [SOAP-ENV:Client] looks like we got no XML
document in
c:\Inetpub\wwwroot\Php\DummyWebService\MyWebServerClient.php:13
Stack trace:
#0 c:\Inetpub\wwwroot\Php\DummyWebService\MyWebServerClient.php(13):
SoapClient->__call('getQuote', Array)
#1 c:\Inetpub\wwwroot\Php\DummyWebService\MyWebServerClient.php(13):
SoapClient->getQuote('ibm')
#2 {main}
Enabling Trace & Disabling exceptions like this:
$x = SoapClient(WSDL, array("trace"=>1, "exceptions"=>0));
and the problem goes away.
This means I can't enable exceptions with the Soap Client.
Reproduce code:
---
$client = new SoapClient("stockquote.wsdl";
try
{
$client->getQuote("ibm");
echo $client->__getLastResponse();
} catch (SoapFault $exception) {
echo $exception;
}
Expected result:
98.42
Actual result:
--
SoapFault exception: [SOAP-ENV:Client] looks like we got no XML
document in
c:\Inetpub\wwwroot\Php\DummyWebService\MyWebServerClient.php:13
Stack trace:
#0 c:\Inetpub\wwwroot\Php\DummyWebService\MyWebServerClient.php(13):
SoapClient->__call('getQuote', Array)
#1 c:\Inetpub\wwwroot\Php\DummyWebService\MyWebServerClient.php(13):
SoapClient->getQuote('ibm')
#2 {main}
--
Edit this bug report at http://bugs.php.net/?id=33567&edit=1
