[PHP-BUG] Bug #54744 [NEW]: ob_gzhandler does not work
From: Operating system: win32 PHP version: trunk-SVN-2011-05-16 (snap) Package: Output Control Bug Type: Bug Bug description:ob_gzhandler does not work Description: ob_gzhandler does not work Test script: --- Expected result: prints 'ok' like PHP 5.3.6 Actual result: -- PHP 5.3.99 prints empty buffer -- Edit bug report at http://bugs.php.net/bug.php?id=54744&edit=1 -- Try a snapshot (PHP 5.2): http://bugs.php.net/fix.php?id=54744&r=trysnapshot52 Try a snapshot (PHP 5.3): http://bugs.php.net/fix.php?id=54744&r=trysnapshot53 Try a snapshot (trunk): http://bugs.php.net/fix.php?id=54744&r=trysnapshottrunk Fixed in SVN: http://bugs.php.net/fix.php?id=54744&r=fixed Fixed in SVN and need be documented: http://bugs.php.net/fix.php?id=54744&r=needdocs Fixed in release: http://bugs.php.net/fix.php?id=54744&r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=54744&r=needtrace Need Reproduce Script: http://bugs.php.net/fix.php?id=54744&r=needscript Try newer version: http://bugs.php.net/fix.php?id=54744&r=oldversion Not developer issue: http://bugs.php.net/fix.php?id=54744&r=support Expected behavior: http://bugs.php.net/fix.php?id=54744&r=notwrong Not enough info: http://bugs.php.net/fix.php?id=54744&r=notenoughinfo Submitted twice: http://bugs.php.net/fix.php?id=54744&r=submittedtwice register_globals: http://bugs.php.net/fix.php?id=54744&r=globals PHP 4 support discontinued: http://bugs.php.net/fix.php?id=54744&r=php4 Daylight Savings:http://bugs.php.net/fix.php?id=54744&r=dst IIS Stability: http://bugs.php.net/fix.php?id=54744&r=isapi Install GNU Sed: http://bugs.php.net/fix.php?id=54744&r=gnused Floating point limitations: http://bugs.php.net/fix.php?id=54744&r=float No Zend Extensions: http://bugs.php.net/fix.php?id=54744&r=nozend MySQL Configuration Error: http://bugs.php.net/fix.php?id=54744&r=mysqlcfg
Bug #54743 [Opn->Bgs]: parse_ini_file() does not allow the word 'no' as part of ini values
Edit report at http://bugs.php.net/bug.php?id=54743&edit=1 ID: 54743 Updated by: johan...@php.net Reported by:adam at papsy dot net Summary:parse_ini_file() does not allow the word 'no' as part of ini values -Status: Open +Status: Bogus Type: Bug Package:PHP options/info functions Operating System: Windows 7 (x64) PHP Version:5.3.6 Block user comment: N Private report: N New Comment: Thank you for taking the time to write to us, but this is not a bug. Please double-check the documentation available at http://www.php.net/manual/ and the instructions on how to report a bug at http://bugs.php.net/how-to-report.php Please quote free text. ERR_GENERIC="Sorry, no results could be found." The parser we are using is relatively simple. Previous Comments: [2011-05-16 07:07:39] adam at papsy dot net Description: This is my first time filing a bug report here so if I've left out anything that may be needed, please let me know. The issue arises when calling parse_ini_file on a file that contains the word "no" as part of _any_ value. Additionally, this error seems to prevent the entire INI file from being loaded properly. In my actual code, database settings are defined first and then error messages second (and one of the error messages contain the word no). When this bug is encountered, the database connection fails due to the previous settings not being parsed. Lastly, this may be a re-post of: http://bugs.php.net/50340 Test script: --- example.php: config.ini: [ERRORS] ERR_GENERIC=Sorry, no results could be found. Expected result: No message should be displayed, and the resulting array should be assigned to $ini_data. Actual result: -- Warning: syntax error, unexpected BOOL_FALSE in required/config.ini on line 2 -- Edit this bug report at http://bugs.php.net/bug.php?id=54743&edit=1
Bug #54491 [Opn->Fbk]: Crash during shutdown sequence
Edit report at http://bugs.php.net/bug.php?id=54491&edit=1 ID: 54491 Updated by: johan...@php.net Reported by:msamson at chowly dot com Summary:Crash during shutdown sequence -Status: Open +Status: Feedback Type: Bug Package:Reproducible crash Operating System: Fedora 14 x64 PHP Version:5.3.6 Block user comment: N Private report: N Previous Comments: [2011-05-16 01:12:56] crrodriguez at opensuse dot org msamson at chowly dot com: I reproduced your script, though no crash at all. ./../sapi/cli/php -v PHP 5.3.7-dev (cli) (built: May 15 2011 18:44:44) (DEBUG) Copyright (c) 1997-2011 The PHP Group Zend Engine v2.3.0, Copyright (c) 1998-2011 Zend Technologies Are you totally sure you posted *all* reproduce instructions ? [2011-05-15 23:49:09] crrodriguez at opensuse dot org [2011-04-08 15:50 UTC] msamson at chowly dot com : Can you post the gdb backtrace or a reproduce script ? and script that requires a framework or a third party extension is NOT reproduce code. [2011-04-11 22:24:00] msamson at chowly dot com Just reproduced the bug in Ubuntu 10.10 i386 with a php 5.3.6 ppa For a total of 2 different computers (both F14 x64) and 4 virtual machines: Fedora x64 RPM Fedora x64 Source Ubuntu x64 PPA Ubuntu x86 PPA [2011-04-08 17:50:57] msamson at chowly dot com Valgrind output of `php webroot/index.php` zend_mm_heap corrupted ==3214== ==3214== HEAP SUMMARY: ==3214== in use at exit: 7,084,078 bytes in 14,840 blocks ==3214== total heap usage: 16,202 allocs, 1,362 frees, 7,502,798 bytes allocated ==3214== ==3214== LEAK SUMMARY: ==3214==definitely lost: 0 bytes in 0 blocks ==3214==indirectly lost: 0 bytes in 0 blocks ==3214== possibly lost: 5,259,364 bytes in 1,386 blocks ==3214==still reachable: 1,824,714 bytes in 13,454 blocks ==3214== suppressed: 0 bytes in 0 blocks ==3214== Rerun with --leak-check=full to see details of leaked memory ==3214== ==3214== For counts of detected and suppressed errors, rerun with: -v ==3214== ERROR SUMMARY: 0 errors from 0 contexts (suppressed: 42 from 8) [2011-04-08 17:05:12] msamson at chowly dot com No, the crash also occurs when the mongo.so extension is not loaded. At first, it thought it was the culprit, but it happens without mongo being loaded. One thing, the CLI version seems to be more resilient, it needs more data loaded to crash, whereas with the apache module, it's always crashing. Chromium reports `Error 324 (net::ERR_EMPTY_RESPONSE): Unknown error` when accessing a url. I was able to get a backtrace (with no execute or zbacktrace output) and around frame 30-ish, it specifies entering the shutdown sequence, cleaning up a closure and then the crash. Changing the summary to better reflect the 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/bug.php?id=54491 -- Edit this bug report at http://bugs.php.net/bug.php?id=54491&edit=1
Bug #54491 [Com]: Crash during shutdown sequence
Edit report at http://bugs.php.net/bug.php?id=54491&edit=1 ID: 54491 Comment by: msamson at chowly dot com Reported by:msamson at chowly dot com Summary:Crash during shutdown sequence Status: Feedback Type: Bug Package:Reproducible crash Operating System: Fedora 14 x64 PHP Version:5.3.6 Block user comment: N Private report: N New Comment: I will test with 5.3.7, but 5.3.5 works like a charm running the exact same code. Previous Comments: [2011-05-16 01:12:56] crrodriguez at opensuse dot org msamson at chowly dot com: I reproduced your script, though no crash at all. ./../sapi/cli/php -v PHP 5.3.7-dev (cli) (built: May 15 2011 18:44:44) (DEBUG) Copyright (c) 1997-2011 The PHP Group Zend Engine v2.3.0, Copyright (c) 1998-2011 Zend Technologies Are you totally sure you posted *all* reproduce instructions ? [2011-05-15 23:49:09] crrodriguez at opensuse dot org [2011-04-08 15:50 UTC] msamson at chowly dot com : Can you post the gdb backtrace or a reproduce script ? and script that requires a framework or a third party extension is NOT reproduce code. [2011-04-11 22:24:00] msamson at chowly dot com Just reproduced the bug in Ubuntu 10.10 i386 with a php 5.3.6 ppa For a total of 2 different computers (both F14 x64) and 4 virtual machines: Fedora x64 RPM Fedora x64 Source Ubuntu x64 PPA Ubuntu x86 PPA [2011-04-08 17:50:57] msamson at chowly dot com Valgrind output of `php webroot/index.php` zend_mm_heap corrupted ==3214== ==3214== HEAP SUMMARY: ==3214== in use at exit: 7,084,078 bytes in 14,840 blocks ==3214== total heap usage: 16,202 allocs, 1,362 frees, 7,502,798 bytes allocated ==3214== ==3214== LEAK SUMMARY: ==3214==definitely lost: 0 bytes in 0 blocks ==3214==indirectly lost: 0 bytes in 0 blocks ==3214== possibly lost: 5,259,364 bytes in 1,386 blocks ==3214==still reachable: 1,824,714 bytes in 13,454 blocks ==3214== suppressed: 0 bytes in 0 blocks ==3214== Rerun with --leak-check=full to see details of leaked memory ==3214== ==3214== For counts of detected and suppressed errors, rerun with: -v ==3214== ERROR SUMMARY: 0 errors from 0 contexts (suppressed: 42 from 8) [2011-04-08 17:05:12] msamson at chowly dot com No, the crash also occurs when the mongo.so extension is not loaded. At first, it thought it was the culprit, but it happens without mongo being loaded. One thing, the CLI version seems to be more resilient, it needs more data loaded to crash, whereas with the apache module, it's always crashing. Chromium reports `Error 324 (net::ERR_EMPTY_RESPONSE): Unknown error` when accessing a url. I was able to get a backtrace (with no execute or zbacktrace output) and around frame 30-ish, it specifies entering the shutdown sequence, cleaning up a closure and then the crash. Changing the summary to better reflect the 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/bug.php?id=54491 -- Edit this bug report at http://bugs.php.net/bug.php?id=54491&edit=1
Bug #54721 [Opn->Asn]: crypt function
Edit report at http://bugs.php.net/bug.php?id=54721&edit=1 ID: 54721 Updated by: tony2...@php.net Reported by:os at irj dot ru Summary:crypt function -Status: Open +Status: Assigned Type: Bug Package:*Encryption and hash functions Operating System: Windows 7 x64 PHP Version:5.3.6 -Assigned To: +Assigned To:pajoye Block user comment: N Private report: N Previous Comments: [2011-05-13 06:16:20] os at irj dot ru At Windows XP Expected result: $1$dW0.is5.$em49ePD07X75OTvpVod410 Actual result: C:\tmp>php test.php $1$dW0.is5.$UW7SlpXxFDXZ9zHcYQy.l/ C:\tmp>php test.php $1$dW0.is5.$RS2jtU/Pp9KpSl.upfU3B. C:\tmp>php test.php $1$dW0.is5.$RS2jtU/Pp9KpSl.upfU3B. C:\tmp>php test.php $1$dW0.is5.$RS2jtU/Pp9KpSl.upfU3B. C:\tmp>php test.php C:\tmp>php -v PHP 5.3.6 (cli) (built: Mar 17 2011 10:37:07) Copyright (c) 1997-2011 The PHP Group Zend Engine v2.3.0, Copyright (c) 1998-2011 Zend Technologies [2011-05-13 06:06:23] os at irj dot ru >From download page I downloaded VC9 x86 Thread Safe (2011-Mar-22 13:27:32) as ZIP arhive, unzip it and run test script at office using cli interface on Microsoft Windows 7 x86, bug too. Expected result: $1$dW0.is5.$em49ePD07X75OTvpVod410 Actual result: D:\tmp>php test.php $1$dW0.is5.$EkFno5M.sWHzVKG.KcE4g. D:\tmp>php test.php $1$dW0.is5.$C08LtG..f5qYCBEqaEaeV. D:\tmp>php test.php $1$dW0.is5.$U.zA4AF2/AvLMpxAdd57x1 D:\tmp>php test.php $1$dW0.is5.$FO6NpJOzWGbHX3Al2BRcU1 D:\tmp>php test.php $1$dW0.is5.$OoBfHS6yulKgQHVDZ8XLx/ D:\tmp>php -v PHP 5.3.6 (cli) (built: Mar 17 2011 10:37:07) Copyright (c) 1997-2011 The PHP Group Zend Engine v2.3.0, Copyright (c) 1998-2011 Zend Technologies D:\tmp> [2011-05-12 18:58:23] os at irj dot ru Sorry, in cli mode bug too (in previos command I use a old CLI php) This is a correct log D:\Web\var\avers.localhost>D:\Web\php53\php.exe D:\Web\var\avers.localhost\test. php $1$dW0.is5.$.O4MUs7rYRmlSuPIA16Jt. D:\Web\var\avers.localhost>D:\Web\php53\php.exe D:\Web\var\avers.localhost\test. php $1$dW0.is5.$sVRmxDm7.B8xcTu1HZKf6/ D:\Web\var\avers.localhost>D:\Web\php53\php.exe D:\Web\var\avers.localhost\test. php $1$dW0.is5.$zI8c4NaU.KzK2y5u.W4Ax. D:\Web\var\avers.localhost>D:\Web\php53\php.exe -v PHP 5.3.6 (cli) (built: Mar 17 2011 10:37:07) Copyright (c) 1997-2011 The PHP Group Zend Engine v2.3.0, Copyright (c) 1998-2011 Zend Technologies D:\Web\var\avers.localhost>D:\curl\curl.exe http://avers.localhost/test.php $1$dW0.is5.$PD4o/IBVjS2AVWa1.Rpdi/ D:\Web\var\avers.localhost>D:\curl\curl.exe http://avers.localhost/test.php $1$dW0.is5.$PD4o/IBVjS2AVWa1.Rpdi/ D:\Web\var\avers.localhost>..\..\apache22\bin\httpd.exe -k restart httpd.exe: Could not reliably determine the server's fully qualified domain name , using 192.168.0.240 for ServerName D:\Web\var\avers.localhost>D:\curl\curl.exe http://avers.localhost/test.php $1$dW0.is5.$.y5yjTLPgypzeHv0FU7zW0 D:\Web\var\avers.localhost>D:\Web\php53\php.exe D:\Web\var\avers.localhost\test .php $1$dW0.is5.$m.YjcIs.joLsQHQGZ0bxn/ D:\Web\var\avers.localhost> [2011-05-12 18:50:22] os at irj dot ru In CLI mode crypt function work normaly, but as apache 2 module bug present CMD Log: Microsoft Windows [Version 6.1.7601] (c) ÐоÑпоÑаÑÐ¸Ñ ÐайкÑоÑоÑÑ (Microsoft Corp.), 2009. ÐÑе пÑава заÑиÑенÑ. C:\Windows\system32>cd D:\Web\var\avers.localhost C:\Windows\system32>d: D:\Web\var\avers.localhost>D:\Web\bin\php\php.exe D:\Web\var\avers.localhost\te st.php $1$dW0.is5.$em49ePD07X75OTvpVod410 D:\Web\var\avers.localhost>D:\curl\curl.exe http://avers.localhost/test.php $1$dW0.is5.$d2QAXWA.uqHWaY1KopvYr. D:\Web\var\avers.localhost>..\..\apache22\bin\httpd.exe -k restart httpd.exe: Could not reliably determine the server's fully qualified domain name , using 192.168.0.240 for ServerName D:\Web\var\avers.localhost>D:\curl\curl.exe http://avers.localhost/test.php $1$dW0.is5.$PD4o/IBVjS2AVWa1.Rpdi/ D:\Web\var\avers.localhost> [2011-05-12 18:32:55] paj...@php.net The browsers have nothing to do with the server side running code. Please try using the CLI interface (cmd line) to confirm the results. 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/bug.php?id=54721 -- Edit this bug report at http://bugs.p
Bug #54721 [Asn]: crypt function
Edit report at http://bugs.php.net/bug.php?id=54721&edit=1 ID: 54721 Updated by: paj...@php.net Reported by:os at irj dot ru Summary:crypt function Status: Assigned Type: Bug Package:*Encryption and hash functions Operating System: Windows 7 x64 PHP Version:5.3.6 Assigned To:pajoye Block user comment: N Private report: N New Comment: Confirmed. Seems to be only happening in the TS API. Previous Comments: [2011-05-13 06:16:20] os at irj dot ru At Windows XP Expected result: $1$dW0.is5.$em49ePD07X75OTvpVod410 Actual result: C:\tmp>php test.php $1$dW0.is5.$UW7SlpXxFDXZ9zHcYQy.l/ C:\tmp>php test.php $1$dW0.is5.$RS2jtU/Pp9KpSl.upfU3B. C:\tmp>php test.php $1$dW0.is5.$RS2jtU/Pp9KpSl.upfU3B. C:\tmp>php test.php $1$dW0.is5.$RS2jtU/Pp9KpSl.upfU3B. C:\tmp>php test.php C:\tmp>php -v PHP 5.3.6 (cli) (built: Mar 17 2011 10:37:07) Copyright (c) 1997-2011 The PHP Group Zend Engine v2.3.0, Copyright (c) 1998-2011 Zend Technologies [2011-05-13 06:06:23] os at irj dot ru >From download page I downloaded VC9 x86 Thread Safe (2011-Mar-22 13:27:32) as ZIP arhive, unzip it and run test script at office using cli interface on Microsoft Windows 7 x86, bug too. Expected result: $1$dW0.is5.$em49ePD07X75OTvpVod410 Actual result: D:\tmp>php test.php $1$dW0.is5.$EkFno5M.sWHzVKG.KcE4g. D:\tmp>php test.php $1$dW0.is5.$C08LtG..f5qYCBEqaEaeV. D:\tmp>php test.php $1$dW0.is5.$U.zA4AF2/AvLMpxAdd57x1 D:\tmp>php test.php $1$dW0.is5.$FO6NpJOzWGbHX3Al2BRcU1 D:\tmp>php test.php $1$dW0.is5.$OoBfHS6yulKgQHVDZ8XLx/ D:\tmp>php -v PHP 5.3.6 (cli) (built: Mar 17 2011 10:37:07) Copyright (c) 1997-2011 The PHP Group Zend Engine v2.3.0, Copyright (c) 1998-2011 Zend Technologies D:\tmp> [2011-05-12 18:58:23] os at irj dot ru Sorry, in cli mode bug too (in previos command I use a old CLI php) This is a correct log D:\Web\var\avers.localhost>D:\Web\php53\php.exe D:\Web\var\avers.localhost\test. php $1$dW0.is5.$.O4MUs7rYRmlSuPIA16Jt. D:\Web\var\avers.localhost>D:\Web\php53\php.exe D:\Web\var\avers.localhost\test. php $1$dW0.is5.$sVRmxDm7.B8xcTu1HZKf6/ D:\Web\var\avers.localhost>D:\Web\php53\php.exe D:\Web\var\avers.localhost\test. php $1$dW0.is5.$zI8c4NaU.KzK2y5u.W4Ax. D:\Web\var\avers.localhost>D:\Web\php53\php.exe -v PHP 5.3.6 (cli) (built: Mar 17 2011 10:37:07) Copyright (c) 1997-2011 The PHP Group Zend Engine v2.3.0, Copyright (c) 1998-2011 Zend Technologies D:\Web\var\avers.localhost>D:\curl\curl.exe http://avers.localhost/test.php $1$dW0.is5.$PD4o/IBVjS2AVWa1.Rpdi/ D:\Web\var\avers.localhost>D:\curl\curl.exe http://avers.localhost/test.php $1$dW0.is5.$PD4o/IBVjS2AVWa1.Rpdi/ D:\Web\var\avers.localhost>..\..\apache22\bin\httpd.exe -k restart httpd.exe: Could not reliably determine the server's fully qualified domain name , using 192.168.0.240 for ServerName D:\Web\var\avers.localhost>D:\curl\curl.exe http://avers.localhost/test.php $1$dW0.is5.$.y5yjTLPgypzeHv0FU7zW0 D:\Web\var\avers.localhost>D:\Web\php53\php.exe D:\Web\var\avers.localhost\test .php $1$dW0.is5.$m.YjcIs.joLsQHQGZ0bxn/ D:\Web\var\avers.localhost> [2011-05-12 18:50:22] os at irj dot ru In CLI mode crypt function work normaly, but as apache 2 module bug present CMD Log: Microsoft Windows [Version 6.1.7601] (c) ÐоÑпоÑаÑÐ¸Ñ ÐайкÑоÑоÑÑ (Microsoft Corp.), 2009. ÐÑе пÑава заÑиÑенÑ. C:\Windows\system32>cd D:\Web\var\avers.localhost C:\Windows\system32>d: D:\Web\var\avers.localhost>D:\Web\bin\php\php.exe D:\Web\var\avers.localhost\te st.php $1$dW0.is5.$em49ePD07X75OTvpVod410 D:\Web\var\avers.localhost>D:\curl\curl.exe http://avers.localhost/test.php $1$dW0.is5.$d2QAXWA.uqHWaY1KopvYr. D:\Web\var\avers.localhost>..\..\apache22\bin\httpd.exe -k restart httpd.exe: Could not reliably determine the server's fully qualified domain name , using 192.168.0.240 for ServerName D:\Web\var\avers.localhost>D:\curl\curl.exe http://avers.localhost/test.php $1$dW0.is5.$PD4o/IBVjS2AVWa1.Rpdi/ D:\Web\var\avers.localhost> [2011-05-12 18:32:55] paj...@php.net The browsers have nothing to do with the server side running code. Please try using the CLI interface (cmd line) to confirm the results. 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/bug.php?id=54721 -- Edit this bug r
Req #54717 [Com]: stream_set_timeout doesn't work for STDIO streams
Edit report at http://bugs.php.net/bug.php?id=54717&edit=1
ID: 54717
Comment by: wuchba at yahoo dot de
Reported by:wuschba at yahoo dot de
Summary:stream_set_timeout doesn't work for STDIO streams
Status: Open
Type: Feature/Change Request
Package:Streams related
Operating System: Linux
PHP Version:5.3.6
Block user comment: N
Private report: N
New Comment:
Thanks for your fast reply!
You are right: set_blocking_mode works under Linux. I don't know what I
made wrong to find my test-cases not working, so sorry for that!
With set_blocking_mode, I was able implement what I need without using
stream_set_timeout, so I guess a feature request is not necessary (at
least for my cases).
Perhaps the documentation for stream_set_timeout should be changed to be
more specific? It says "As of PHP 4.3, this function can (potentially)
work on any kind of stream.", but it should say that the read timeout is
implemented only for sockets and that it doesn't work on Windows at all.
Previous Comments:
[2011-05-16 00:49:30] cataphr...@php.net
I can't reproduce this for stream_set_blocking -- it works as expected:
From manual page:
http://www.php.net/function.stream-set-timeout#Changelog
---
When open a stream with popen or proc_open, stream_set_timeout or
stream_ set_ blocking fail (tested on Linux and Windows), while the
manual says:
"As of PHP 4.3, this function can (potentially) work on any kind of
stream."
(while 'potentially' of course might mean everything ;-))
Test script:
---
$proc[0] = popen("/usr/srv/php /my/folder/myscript.php 0 &", "r");
$proc[1] = popen("/usr/srv/php /my/folder/myscript.php 1 &", "r");
if (!stream_set_timeout($proc[0], 1, 0)) print "stream_set_timeout
failed on stream 1";
if (!stream_set_timeout($proc[1], 1, 0)) print "stream_set_timeout
failed on stream 2";
Expected result:
It should NOT output:
stream_set_timeout failed on stream 1
stream_set_timeout failed on stream 2
--
Edit this bug report at http://bugs.php.net/bug.php?id=54717&edit=1
Bug #54721 [Asn]: crypt function
Edit report at http://bugs.php.net/bug.php?id=54721&edit=1 ID: 54721 Updated by: paj...@php.net Reported by:os at irj dot ru Summary:crypt function Status: Assigned Type: Bug Package:*Encryption and hash functions Operating System: Windows 7 x64 PHP Version:5.3.6 Assigned To:pajoye Block user comment: N Private report: N New Comment: Please note that as this code may or should produce similar results on all platforms or builds, it is not correct. MD5 salt is max. 12 characters as described in the manual and how the extra characters are treated are implementation specific. Use blowfish or other stronger algorithm if you like to use a bigger salt. Previous Comments: [2011-05-16 16:46:03] paj...@php.net Confirmed. Seems to be only happening in the TS API. [2011-05-13 06:16:20] os at irj dot ru At Windows XP Expected result: $1$dW0.is5.$em49ePD07X75OTvpVod410 Actual result: C:\tmp>php test.php $1$dW0.is5.$UW7SlpXxFDXZ9zHcYQy.l/ C:\tmp>php test.php $1$dW0.is5.$RS2jtU/Pp9KpSl.upfU3B. C:\tmp>php test.php $1$dW0.is5.$RS2jtU/Pp9KpSl.upfU3B. C:\tmp>php test.php $1$dW0.is5.$RS2jtU/Pp9KpSl.upfU3B. C:\tmp>php test.php C:\tmp>php -v PHP 5.3.6 (cli) (built: Mar 17 2011 10:37:07) Copyright (c) 1997-2011 The PHP Group Zend Engine v2.3.0, Copyright (c) 1998-2011 Zend Technologies [2011-05-13 06:06:23] os at irj dot ru >From download page I downloaded VC9 x86 Thread Safe (2011-Mar-22 13:27:32) as ZIP arhive, unzip it and run test script at office using cli interface on Microsoft Windows 7 x86, bug too. Expected result: $1$dW0.is5.$em49ePD07X75OTvpVod410 Actual result: D:\tmp>php test.php $1$dW0.is5.$EkFno5M.sWHzVKG.KcE4g. D:\tmp>php test.php $1$dW0.is5.$C08LtG..f5qYCBEqaEaeV. D:\tmp>php test.php $1$dW0.is5.$U.zA4AF2/AvLMpxAdd57x1 D:\tmp>php test.php $1$dW0.is5.$FO6NpJOzWGbHX3Al2BRcU1 D:\tmp>php test.php $1$dW0.is5.$OoBfHS6yulKgQHVDZ8XLx/ D:\tmp>php -v PHP 5.3.6 (cli) (built: Mar 17 2011 10:37:07) Copyright (c) 1997-2011 The PHP Group Zend Engine v2.3.0, Copyright (c) 1998-2011 Zend Technologies D:\tmp> [2011-05-12 18:58:23] os at irj dot ru Sorry, in cli mode bug too (in previos command I use a old CLI php) This is a correct log D:\Web\var\avers.localhost>D:\Web\php53\php.exe D:\Web\var\avers.localhost\test. php $1$dW0.is5.$.O4MUs7rYRmlSuPIA16Jt. D:\Web\var\avers.localhost>D:\Web\php53\php.exe D:\Web\var\avers.localhost\test. php $1$dW0.is5.$sVRmxDm7.B8xcTu1HZKf6/ D:\Web\var\avers.localhost>D:\Web\php53\php.exe D:\Web\var\avers.localhost\test. php $1$dW0.is5.$zI8c4NaU.KzK2y5u.W4Ax. D:\Web\var\avers.localhost>D:\Web\php53\php.exe -v PHP 5.3.6 (cli) (built: Mar 17 2011 10:37:07) Copyright (c) 1997-2011 The PHP Group Zend Engine v2.3.0, Copyright (c) 1998-2011 Zend Technologies D:\Web\var\avers.localhost>D:\curl\curl.exe http://avers.localhost/test.php $1$dW0.is5.$PD4o/IBVjS2AVWa1.Rpdi/ D:\Web\var\avers.localhost>D:\curl\curl.exe http://avers.localhost/test.php $1$dW0.is5.$PD4o/IBVjS2AVWa1.Rpdi/ D:\Web\var\avers.localhost>..\..\apache22\bin\httpd.exe -k restart httpd.exe: Could not reliably determine the server's fully qualified domain name , using 192.168.0.240 for ServerName D:\Web\var\avers.localhost>D:\curl\curl.exe http://avers.localhost/test.php $1$dW0.is5.$.y5yjTLPgypzeHv0FU7zW0 D:\Web\var\avers.localhost>D:\Web\php53\php.exe D:\Web\var\avers.localhost\test .php $1$dW0.is5.$m.YjcIs.joLsQHQGZ0bxn/ D:\Web\var\avers.localhost> [2011-05-12 18:50:22] os at irj dot ru In CLI mode crypt function work normaly, but as apache 2 module bug present CMD Log: Microsoft Windows [Version 6.1.7601] (c) ÐоÑпоÑаÑÐ¸Ñ ÐайкÑоÑоÑÑ (Microsoft Corp.), 2009. ÐÑе пÑава заÑиÑенÑ. C:\Windows\system32>cd D:\Web\var\avers.localhost C:\Windows\system32>d: D:\Web\var\avers.localhost>D:\Web\bin\php\php.exe D:\Web\var\avers.localhost\te st.php $1$dW0.is5.$em49ePD07X75OTvpVod410 D:\Web\var\avers.localhost>D:\curl\curl.exe http://avers.localhost/test.php $1$dW0.is5.$d2QAXWA.uqHWaY1KopvYr. D:\Web\var\avers.localhost>..\..\apache22\bin\httpd.exe -k restart httpd.exe: Could not reliably determine the server's fully qualified domain name , using 192.168.0.240 for ServerName D:\Web\var\avers.localhost>D:\curl\curl.exe http://avers.localhost/test.php $1$dW0.is5.$PD4o/IBVjS2AVWa1.Rpdi/ D:\Web\var\avers.localhost> The r
Bug #53782 [ReO->Csd]: foreach throws irrelevant exception
Edit report at http://bugs.php.net/bug.php?id=53782&edit=1
ID: 53782
Updated by: johan...@php.net
Reported by:david at grudl dot com
Summary:foreach throws irrelevant exception
-Status: Re-Opened
+Status: Closed
Type: Bug
Package:PDO related
Operating System: Windows 7
PHP Version:Irrelevant
-Assigned To:
+Assigned To:johannes
Block user comment: N
Private report: N
New Comment:
This bug has been fixed in SVN.
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.
Previous Comments:
[2011-05-16 17:37:40] johan...@php.net
Automatic comment from SVN on behalf of johannes
Revision: http://svn.php.net/viewvc/?view=revision&revision=311088
Log: - Fix Bug #53782 (foreach throws irrelevant exception)
[2011-05-12 16:31:09] vr...@php.net
This seems like a real bug, example is correct.
[2011-05-10 14:37:33] david at grudl dot com
This is a serious bug in the PDO. Look at the example more closely.
Variable $res has nothing to do with errenous query.
[2011-05-10 10:06:47] u...@php.net
Running errenous query and not expecting exception is bogus.
[2011-01-18 21:30:47] david at grudl dot com
Description:
Iteration using foreach throws "previous" and irrelevant exception.
Exception is throwed after last iteration.
Test script:
---
$conn = new PDO("mysql:dbname=test");
$conn->setAttribute(PDO::ATTR_ERRMODE, PDO::ERRMODE_EXCEPTION);
$res = $conn->query('SELECT * FROM categories');
try {
$conn->query('ERROR');
} catch (PDOException $e) { // exception is catched
}
foreach ($res as $k => $v); // now is throwed exception $e !!!
Expected result:
do nothing
--
Edit this bug report at http://bugs.php.net/bug.php?id=53782&edit=1
[PHP-BUG] Bug #54758 [NEW]: GetSize() returns negative values for large file sizes
From:
Operating system: Windows Server 2008
PHP version: 5.3.6
Package: Directory function related
Bug Type: Bug
Bug description:GetSize() returns negative values for large file sizes
Description:
When using GetFile() as documented
http://php.net/manual/en/directoryiterator.getsize.php if you run the
function on a large file you get negative values which are wrong. I haven't
got the exact file size that this happens at, but I have tested with files
of 7GB and over, and always get the same result. tested using the function
in the test script.
Test script:
---
function dirSize($directory) {
$size = 0;
foreach(new RecursiveIteratorIterator(new
RecursiveDirectoryIterator($directory)) as $file){
$size+=$file->getSize();
}
return $size;
}
Then ran function using input value of a directory with a single file of
8,510,398,464 bytes in size.
Expected result:
8310936 KB
Actual result:
--
-77674.63
--
Edit bug report at http://bugs.php.net/bug.php?id=54758&edit=1
--
Try a snapshot (PHP 5.2):
http://bugs.php.net/fix.php?id=54758&r=trysnapshot52
Try a snapshot (PHP 5.3):
http://bugs.php.net/fix.php?id=54758&r=trysnapshot53
Try a snapshot (trunk):
http://bugs.php.net/fix.php?id=54758&r=trysnapshottrunk
Fixed in SVN:
http://bugs.php.net/fix.php?id=54758&r=fixed
Fixed in SVN and need be documented:
http://bugs.php.net/fix.php?id=54758&r=needdocs
Fixed in release:
http://bugs.php.net/fix.php?id=54758&r=alreadyfixed
Need backtrace:
http://bugs.php.net/fix.php?id=54758&r=needtrace
Need Reproduce Script:
http://bugs.php.net/fix.php?id=54758&r=needscript
Try newer version:
http://bugs.php.net/fix.php?id=54758&r=oldversion
Not developer issue:
http://bugs.php.net/fix.php?id=54758&r=support
Expected behavior:
http://bugs.php.net/fix.php?id=54758&r=notwrong
Not enough info:
http://bugs.php.net/fix.php?id=54758&r=notenoughinfo
Submitted twice:
http://bugs.php.net/fix.php?id=54758&r=submittedtwice
register_globals:
http://bugs.php.net/fix.php?id=54758&r=globals
PHP 4 support discontinued: http://bugs.php.net/fix.php?id=54758&r=php4
Daylight Savings:http://bugs.php.net/fix.php?id=54758&r=dst
IIS Stability:
http://bugs.php.net/fix.php?id=54758&r=isapi
Install GNU Sed:
http://bugs.php.net/fix.php?id=54758&r=gnused
Floating point limitations:
http://bugs.php.net/fix.php?id=54758&r=float
No Zend Extensions:
http://bugs.php.net/fix.php?id=54758&r=nozend
MySQL Configuration Error:
http://bugs.php.net/fix.php?id=54758&r=mysqlcfg
Bug #54758 [Opn]: GetSize() returns negative values for large file sizes
Edit report at http://bugs.php.net/bug.php?id=54758&edit=1
ID: 54758
User updated by:noodleyman at gmail dot com
Reported by:noodleyman at gmail dot com
Summary:GetSize() returns negative values for large file
sizes
Status: Open
Type: Bug
Package:Directory function related
Operating System: Windows Server 2008
PHP Version:5.3.6
Block user comment: N
Private report: N
New Comment:
just realised I typed the wrong function name in the description by
mistake. it should read "When using GetSize()" not "When using
GetFile()"
Previous Comments:
[2011-05-16 21:46:57] noodleyman at gmail dot com
Description:
When using GetFile() as documented
http://php.net/manual/en/directoryiterator.getsize.php if you run the
function on a large file you get negative values which are wrong. I
haven't got the exact file size that this happens at, but I have tested
with files of 7GB and over, and always get the same result. tested using
the function in the test script.
Test script:
---
function dirSize($directory) {
$size = 0;
foreach(new RecursiveIteratorIterator(new
RecursiveDirectoryIterator($directory)) as $file){
$size+=$file->getSize();
}
return $size;
}
Then ran function using input value of a directory with a single file of
8,510,398,464 bytes in size.
Expected result:
8310936 KB
Actual result:
--
-77674.63
--
Edit this bug report at http://bugs.php.net/bug.php?id=54758&edit=1
[PHP-BUG] Bug #54759 [NEW]: parse_url function turns a tab character into an underscore
From:
Operating system: Windows Server 2008 R2
PHP version: 5.3.6
Package: HTTP related
Bug Type: Bug
Bug description:parse_url function turns a tab character into an underscore
Description:
The parse_url function turns the tab character into an underscore. This
turns an invalid URL into a valid one. If you are attempting to validate
user input with parse_url then it will pass validation even though tab is
an invalid character in a host name or FQDN. It may be difficult to see in
the example below but there is a tab.
Test script:
---
http://testurl";
var_dump(parse_url($host));
?>
Expected result:
array(2) { ["scheme"]=> string(4) "http" ["host"]=> string(8) "test url" }
or
array(2) { ["scheme"]=> string(4) "http" ["host"]=> string(8) "test\turl" }
Actual result:
--
array(2) { ["scheme"]=> string(4) "http" ["host"]=> string(8) "test_url" }
--
Edit bug report at http://bugs.php.net/bug.php?id=54759&edit=1
--
Try a snapshot (PHP 5.2):
http://bugs.php.net/fix.php?id=54759&r=trysnapshot52
Try a snapshot (PHP 5.3):
http://bugs.php.net/fix.php?id=54759&r=trysnapshot53
Try a snapshot (trunk):
http://bugs.php.net/fix.php?id=54759&r=trysnapshottrunk
Fixed in SVN:
http://bugs.php.net/fix.php?id=54759&r=fixed
Fixed in SVN and need be documented:
http://bugs.php.net/fix.php?id=54759&r=needdocs
Fixed in release:
http://bugs.php.net/fix.php?id=54759&r=alreadyfixed
Need backtrace:
http://bugs.php.net/fix.php?id=54759&r=needtrace
Need Reproduce Script:
http://bugs.php.net/fix.php?id=54759&r=needscript
Try newer version:
http://bugs.php.net/fix.php?id=54759&r=oldversion
Not developer issue:
http://bugs.php.net/fix.php?id=54759&r=support
Expected behavior:
http://bugs.php.net/fix.php?id=54759&r=notwrong
Not enough info:
http://bugs.php.net/fix.php?id=54759&r=notenoughinfo
Submitted twice:
http://bugs.php.net/fix.php?id=54759&r=submittedtwice
register_globals:
http://bugs.php.net/fix.php?id=54759&r=globals
PHP 4 support discontinued: http://bugs.php.net/fix.php?id=54759&r=php4
Daylight Savings:http://bugs.php.net/fix.php?id=54759&r=dst
IIS Stability:
http://bugs.php.net/fix.php?id=54759&r=isapi
Install GNU Sed:
http://bugs.php.net/fix.php?id=54759&r=gnused
Floating point limitations:
http://bugs.php.net/fix.php?id=54759&r=float
No Zend Extensions:
http://bugs.php.net/fix.php?id=54759&r=nozend
MySQL Configuration Error:
http://bugs.php.net/fix.php?id=54759&r=mysqlcfg
Bug #54759 [Opn->Bgs]: parse_url function turns a tab character into an underscore
Edit report at http://bugs.php.net/bug.php?id=54759&edit=1
ID: 54759
Updated by: dtajchre...@php.net
Reported by:alexander_leroux at mcafee dot com
Summary:parse_url function turns a tab character into an
underscore
-Status: Open
+Status: Bogus
Type: Bug
Package:HTTP related
Operating System: Windows Server 2008 R2
PHP Version:5.3.6
Block user comment: N
Private report: N
New Comment:
php.net/parse_url explains all of this:
"This function is not meant to validate the given URL, it only breaks it
up into
the above listed parts. Partial URLs are also accepted,
parse_url() tries its best to parse them correctly."
"The URL to parse. Invalid characters are replaced by _."
filter_var($var, FILTER_VALIDATE_URL) should do what you're looking for.
[1] php.net/filter_var
[2] http://codepad.viper-7.com/M2LQor
Previous Comments:
[2011-05-16 22:07:21] alexander_leroux at mcafee dot com
Description:
The parse_url function turns the tab character into an underscore. This
turns an invalid URL into a valid one. If you are attempting to
validate user input with parse_url then it will pass validation even
though tab is an invalid character in a host name or FQDN. It may be
difficult to see in the example below but there is a tab.
Test script:
---
http://testurl";
var_dump(parse_url($host));
?>
Expected result:
array(2) { ["scheme"]=> string(4) "http" ["host"]=> string(8) "test url"
}
or
array(2) { ["scheme"]=> string(4) "http" ["host"]=> string(8)
"test\turl" }
Actual result:
--
array(2) { ["scheme"]=> string(4) "http" ["host"]=> string(8) "test_url"
}
--
Edit this bug report at http://bugs.php.net/bug.php?id=54759&edit=1
Bug #54759 [Bgs]: parse_url function turns a tab character into an underscore
Edit report at http://bugs.php.net/bug.php?id=54759&edit=1
ID: 54759
User updated by:alexander_leroux at mcafee dot com
Reported by:alexander_leroux at mcafee dot com
Summary:parse_url function turns a tab character into an
underscore
Status: Bogus
Type: Bug
Package:HTTP related
Operating System: Windows Server 2008 R2
PHP Version:5.3.6
Block user comment: N
Private report: N
New Comment:
filter_var($var, FILTER_VALIDATE_URL) doesn't handle IPv6 addresses so I
can't use
it. I've gotten around the problem. I just didn't realize _ was
replacing
invalid characters.
Previous Comments:
[2011-05-16 22:25:00] dtajchre...@php.net
php.net/parse_url explains all of this:
"This function is not meant to validate the given URL, it only breaks it
up into
the above listed parts. Partial URLs are also accepted,
parse_url() tries its best to parse them correctly."
"The URL to parse. Invalid characters are replaced by _."
filter_var($var, FILTER_VALIDATE_URL) should do what you're looking for.
[1] php.net/filter_var
[2] http://codepad.viper-7.com/M2LQor
[2011-05-16 22:07:21] alexander_leroux at mcafee dot com
Description:
The parse_url function turns the tab character into an underscore. This
turns an invalid URL into a valid one. If you are attempting to
validate user input with parse_url then it will pass validation even
though tab is an invalid character in a host name or FQDN. It may be
difficult to see in the example below but there is a tab.
Test script:
---
http://testurl";
var_dump(parse_url($host));
?>
Expected result:
array(2) { ["scheme"]=> string(4) "http" ["host"]=> string(8) "test url"
}
or
array(2) { ["scheme"]=> string(4) "http" ["host"]=> string(8)
"test\turl" }
Actual result:
--
array(2) { ["scheme"]=> string(4) "http" ["host"]=> string(8) "test_url"
}
--
Edit this bug report at http://bugs.php.net/bug.php?id=54759&edit=1
Bug #54137 [Com]: file_get_contents POST request sends additional line breaks
Edit report at http://bugs.php.net/bug.php?id=54137&edit=1
ID: 54137
Comment by: spam at abma dot de
Reported by:maurice-php at mertinkat dot net
Summary:file_get_contents POST request sends additional line
breaks
Status: Open
Type: Bug
Package:Streams related
Operating System: all
PHP Version:5.3.5
Block user comment: N
Private report: N
New Comment:
is this the same bug
https://bugs.launchpad.net/ubuntu/+source/php5/+bug/650779 ?
Previous Comments:
[2011-04-26 09:12:02] xiezhenye at gmail dot com
I also meet with this problem.
As http protocol, message body size should exactly match the
content-length. when there exists unwanted "\r\n\r\n", it maybe cause
some unexpected result, as connect resetted by server.
[2011-03-14 18:25:35] christophe dot bliard at trux dot info
I have the same problem here, with PHP 5.3.2 and also 5.2.10.
Another thing that may be interesting: if you do the same HTTP POST
request on a
web server on localhost, then there will not be any "\r\n\r\n" after the
request.
[2011-03-02 14:45:02] maurice-php at mertinkat dot net
Description:
When doing HTTP POST requests using file_get_contents and an appropriate
stream context (http method = POST, content = ...) two additional line
breaks ("\r\n\r\n") are added below the POST message body. This is wrong
according to the default encoding "application/x-www-form-urlencoded"
and has been seen to upset some webservers (content length is
incorrect).
Run the testscript and check the traffic using tcpdump/tcpflow or
wireshark. You'll see additional lines at the end of the message body.
Attached is a very simple patch against http_fopen_wrapper.c from PHP
5.3.5 source which removes sending "\r\n\r\n".
Test script:
---
array(
'method' => 'POST',
'header' => 'Content-Type: application/x-www-form-urlencoded',
'content' => 'a=1&b=2',
)
));
$response = file_get_contents('http://www.php.net/', false, $ctx);
echo $response;
--
Edit this bug report at http://bugs.php.net/bug.php?id=54137&edit=1
[PHP-BUG] Bug #54760 [NEW]: Multiple closure invocations 'using' a static variable crashes engine
From: Operating system: Linux Apache 2.2.17 PHP version: 5.3.6 Package: Scripting Engine problem Bug Type: Bug Bug description:Multiple closure invocations 'using' a static variable crashes engine Description: When a closure is invoked more than once that 'uses' a variable defined with the 'static' keyword, the scripting engine crashes. No output is sent to the browser and server issues no response. If we remove the 'static' keyword from the variable declaration, the issue is resolved. Note that in PHP 5.3.5, this issue was not present. Test script: --- ftp://guest:gu...@bytes1.dyndns.org/PUBLIC/php_bug/php_bug.php Expected result: 123 Actual result: -- No result. Scripting engine crashes. -- Edit bug report at http://bugs.php.net/bug.php?id=54760&edit=1 -- Try a snapshot (PHP 5.2): http://bugs.php.net/fix.php?id=54760&r=trysnapshot52 Try a snapshot (PHP 5.3): http://bugs.php.net/fix.php?id=54760&r=trysnapshot53 Try a snapshot (trunk): http://bugs.php.net/fix.php?id=54760&r=trysnapshottrunk Fixed in SVN: http://bugs.php.net/fix.php?id=54760&r=fixed Fixed in SVN and need be documented: http://bugs.php.net/fix.php?id=54760&r=needdocs Fixed in release: http://bugs.php.net/fix.php?id=54760&r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=54760&r=needtrace Need Reproduce Script: http://bugs.php.net/fix.php?id=54760&r=needscript Try newer version: http://bugs.php.net/fix.php?id=54760&r=oldversion Not developer issue: http://bugs.php.net/fix.php?id=54760&r=support Expected behavior: http://bugs.php.net/fix.php?id=54760&r=notwrong Not enough info: http://bugs.php.net/fix.php?id=54760&r=notenoughinfo Submitted twice: http://bugs.php.net/fix.php?id=54760&r=submittedtwice register_globals: http://bugs.php.net/fix.php?id=54760&r=globals PHP 4 support discontinued: http://bugs.php.net/fix.php?id=54760&r=php4 Daylight Savings:http://bugs.php.net/fix.php?id=54760&r=dst IIS Stability: http://bugs.php.net/fix.php?id=54760&r=isapi Install GNU Sed: http://bugs.php.net/fix.php?id=54760&r=gnused Floating point limitations: http://bugs.php.net/fix.php?id=54760&r=float No Zend Extensions: http://bugs.php.net/fix.php?id=54760&r=nozend MySQL Configuration Error: http://bugs.php.net/fix.php?id=54760&r=mysqlcfg
Bug #32101 [Com]: Exception in unknown on line 0 when throwing exception inside exception handler
Edit report at http://bugs.php.net/bug.php?id=32101&edit=1 ID: 32101 Comment by: paul at annesley dot cc Reported by:ceefour at gauldong dot net Summary:Exception in unknown on line 0 when throwing exception inside exception handler Status: No Feedback Type: Bug Package:Scripting Engine problem Operating System: * PHP Version:5CVS-2005-02-15 Block user comment: N Private report: N New Comment: This was fixed between PHP 5.3.5 and PHP 5.3.6 in the following revision: r307523 | stas | 2011-01-17 08:24:43 +1100 (Mon, 17 Jan 2011) | 2 lines Fix bug #47143, bug #51458 - provide more useful info in bad exception cases It didn't seem to make it into the ChangeLog, though. And it didn't reference this bug.. I guess over the past six years, there's been a lot of duplicate reports! Previous Comments: [2010-06-21 01:40:02] rjonbone at gmail dot com This problem is still present as of PHP 5.3.2 on Ubuntu 10.04 using the following test cases: All result in this error: 'Fatal error: Exception thrown without a stack frame in Unknown on line 0' While I can understand their may be complexities with stack traces, and even file and line numbers in these contexts, the original error message should at least be visible so that it can be debugged and resolved, i.e. Fatal error: Exception (type: Exception, message: 'This message should be visible!') thrown without a stack frame in Unknown on line 0. [2010-03-25 21:32:30] s...@php.net Maybe related to Bug #51394 [2007-10-30 01:00:01] 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". [2007-10-22 08:48:40] j...@php.net Does this still happen using latest CVS snapshot/checkout of PHP 5.2 branch? [2007-10-22 08:47:25] j...@php.net See also bug #43016 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/bug.php?id=32101 -- Edit this bug report at http://bugs.php.net/bug.php?id=32101&edit=1
Req #47143 [Com]: Throwing an exception in a destructor causes a fatal error
Edit report at http://bugs.php.net/bug.php?id=47143&edit=1
ID: 47143
Comment by: paul at annesley dot cc
Reported by:felixcca at yahoo dot ca
Summary:Throwing an exception in a destructor causes a fatal
error
Status: Closed
Type: Feature/Change Request
Package:*General Issues
Operating System: *
PHP Version:5.2.8
Assigned To:stas
Block user comment: N
Private report: N
New Comment:
More specifically, this was fixed between PHP 5.3.5 and PHP 5.3.6 in the
following
revision:
r307523 | stas | 2011-01-17 08:24:43 +1100 (Mon, 17 Jan 2011) | 2 lines
Fix bug #47143, bug #51458 - provide more useful info in bad exception
cases
It didn't seem to make it into the ChangeLog, though.
Previous Comments:
[2011-01-16 22:26:17] s...@php.net
This bug has been fixed in SVN.
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.
[2011-01-16 22:24:45] s...@php.net
Automatic comment from SVN on behalf of stas
Revision: http://svn.php.net/viewvc/?view=revision&revision=307523
Log: Fix bug #47143, bug #51458 - provide more useful info in bad
exception cases
[2009-01-18 08:26:28] felixcca at yahoo dot ca
Sorry, made a mistake on the original error message. It's "Exception
thrown without a stack frame," as stated below, and not "Exception
thrown without a stack trace".
[2009-01-18 05:16:31] felixcca at yahoo dot ca
Description:
Basically a duplicate of #31304, but it seems I can't reopen the ticket
myself since I'm not a dev nor the original poster.
When an exception is thrown in a destructor, the exception is lost, and
a pointless Fatal Error is issued:
Fatal Error: Exception thrown without a stack trace
debug_backtrace() will still get you a stack trace from a destructor
without issuing any error, let alone causing the loss of debugging data.
Also, only wrapping the exception in a try-catch inside the destructor
works, and allows you to just print the exception and exit as if
exceptions really worked in destructors.
Why spit out the Fatal Error?
Reproduce code:
---
Expected result:
Fatal error: Uncaught exception 'Exception' in snippet.php:6
Stack trace:
#0 [internal function]: ExceptionThrower->__destruct()
#1 {main}
thrown in snippet.php on line 6
Actual result:
--
Fatal error: Exception thrown without a stack frame in Unknown on line 0
--
Edit this bug report at http://bugs.php.net/bug.php?id=47143&edit=1
Bug #51458 [Com]: Lack of error context with nested exceptions
Edit report at http://bugs.php.net/bug.php?id=51458&edit=1 ID: 51458 Comment by: paul at annesley dot cc Reported by:nlgordon at gmail dot com Summary:Lack of error context with nested exceptions Status: Closed Type: Bug Package:Unknown/Other Function Operating System: Redhat Linux PHP Version:5.3.2 Assigned To:stas Block user comment: N Private report: N New Comment: More specifically, this was fixed between PHP 5.3.5 and PHP 5.3.6 in the following revision: r307523 | stas | 2011-01-17 08:24:43 +1100 (Mon, 17 Jan 2011) | 2 lines Fix bug #47143, bug #51458 - provide more useful info in bad exception cases It didn't seem to make it into the ChangeLog, though. Previous Comments: [2011-01-16 22:26:38] s...@php.net This bug has been fixed in SVN. 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. [2011-01-16 22:24:47] s...@php.net Automatic comment from SVN on behalf of stas Revision: http://svn.php.net/viewvc/?view=revision&revision=307523 Log: Fix bug #47143, bug #51458 - provide more useful info in bad exception cases [2011-01-09 22:37:32] sailormax at inbox dot lv same problem with 5.2.x after 5.2.5; I had calling unexist function in exception handler. In result PHP returned empty page and didn't write any error in logs. Not very comfortable debug scripts in such conditions... :/ [2010-04-01 23:15:54] nlgordon at gmail dot com Description: In short, if you thrown an exception from within the exception handler, you get an uninformative error message with no contextual information. It makes sense for this case to be a fatal error. We don't want to get recursive throwing of exceptions and spiral to our death. If you create an exception in the error handler without throwing it, it has the correct info about where it was created. This is enough to figure out where the error is coming from. It is at least far more informative and gives you a starting place in a potentially complex code base. >From my quick look at the code in Zend/zend_exceptions.c:94 where this originates. It looks like the exception is there, and that would have file/line num info. Test script: --- http://bugs.php.net/bug.php?id=51458&edit=1
