Bug #51689 [Fbk->Csd]: Date::diff keeps subtracting after Date::sub
Edit report at https://bugs.php.net/bug.php?id=51689&edit=1
ID: 51689
Updated by: ahar...@php.net
Reported by:binarte at gmail dot com
Summary:Date::diff keeps subtracting after Date::sub
-Status: Feedback
+Status: Closed
Type: Bug
Package:Date/time related
Operating System: Ubuntu 10.04
PHP Version:5.3.2
-Assigned To:
+Assigned To:aharvey
Block user comment: N
Private report: N
New Comment:
Cheers; we'll call this fixed then.
Previous Comments:
[2012-03-09 07:38:26] php dot net at doppy dot nl
Result on php 5.3.6:
--
Thu, 31 Dec 2009 00:00:00 +
Thu, 31 Dec 2009 00:00:00 +
Thu, 31 Dec 2009 00:00:00 +
Thu, 31 Dec 2009 00:00:00 +
Thu, 31 Dec 2009 00:00:00 +
Thu, 31 Dec 2009 00:00:00 +
---
This is the expected result.
Recommend closing this.
[2010-04-29 01:11:17] der...@php.net
Please try using this snapshot:
http://snaps.php.net/php5.3-latest.tar.gz
For Windows:
http://windows.php.net/snapshots/
[2010-04-29 00:54:55] binarte at gmail dot com
Description:
After executing a sub() on a DateTime object, for every call of diff(), both
DateTime objects start getting subtracted by the value that was passed on sub().
Test script:
---
date_default_timezone_set('GMT');
$t1 = new DateTime('2010-01-01 00:00:00');
$t2 = new DateTime('2010-01-01 00:00:00');
$dif = new DateInterval('P1D');
$t2->sub($dif);
$t1->sub($dif);
for ($x = 0; $x < 3; $x++) {
$t1->diff($t2);
echo $t1->format("r\n");
echo $t2->format("r\n");
echo "\n";
}
Expected result:
Fri, 01 Jan 2010 00:00:00 +
Fri, 01 Jan 2010 00:00:00 +
Fri, 01 Jan 2010 00:00:00 +
Fri, 01 Jan 2010 00:00:00 +
Fri, 01 Jan 2010 00:00:00 +
Fri, 01 Jan 2010 00:00:00 +
Actual result:
--
Wed, 30 Dec 2009 00:00:00 +
Wed, 30 Dec 2009 00:00:00 +
Tue, 29 Dec 2009 00:00:00 +
Tue, 29 Dec 2009 00:00:00 +
Mon, 28 Dec 2009 00:00:00 +
Mon, 28 Dec 2009 00:00:00 +
--
Edit this bug report at https://bugs.php.net/bug.php?id=51689&edit=1
Bug #51689 [Com]: Date::diff keeps subtracting after Date::sub
Edit report at https://bugs.php.net/bug.php?id=51689&edit=1
ID: 51689
Comment by: php dot net at doppy dot nl
Reported by:binarte at gmail dot com
Summary:Date::diff keeps subtracting after Date::sub
Status: Feedback
Type: Bug
Package:Date/time related
Operating System: Ubuntu 10.04
PHP Version:5.3.2
Block user comment: N
Private report: N
New Comment:
Result on php 5.3.6:
--
Thu, 31 Dec 2009 00:00:00 +
Thu, 31 Dec 2009 00:00:00 +
Thu, 31 Dec 2009 00:00:00 +
Thu, 31 Dec 2009 00:00:00 +
Thu, 31 Dec 2009 00:00:00 +
Thu, 31 Dec 2009 00:00:00 +
---
This is the expected result.
Recommend closing this.
Previous Comments:
[2010-04-29 01:11:17] der...@php.net
Please try using this snapshot:
http://snaps.php.net/php5.3-latest.tar.gz
For Windows:
http://windows.php.net/snapshots/
[2010-04-29 00:54:55] binarte at gmail dot com
Description:
After executing a sub() on a DateTime object, for every call of diff(), both
DateTime objects start getting subtracted by the value that was passed on sub().
Test script:
---
date_default_timezone_set('GMT');
$t1 = new DateTime('2010-01-01 00:00:00');
$t2 = new DateTime('2010-01-01 00:00:00');
$dif = new DateInterval('P1D');
$t2->sub($dif);
$t1->sub($dif);
for ($x = 0; $x < 3; $x++) {
$t1->diff($t2);
echo $t1->format("r\n");
echo $t2->format("r\n");
echo "\n";
}
Expected result:
Fri, 01 Jan 2010 00:00:00 +
Fri, 01 Jan 2010 00:00:00 +
Fri, 01 Jan 2010 00:00:00 +
Fri, 01 Jan 2010 00:00:00 +
Fri, 01 Jan 2010 00:00:00 +
Fri, 01 Jan 2010 00:00:00 +
Actual result:
--
Wed, 30 Dec 2009 00:00:00 +
Wed, 30 Dec 2009 00:00:00 +
Tue, 29 Dec 2009 00:00:00 +
Tue, 29 Dec 2009 00:00:00 +
Mon, 28 Dec 2009 00:00:00 +
Mon, 28 Dec 2009 00:00:00 +
--
Edit this bug report at https://bugs.php.net/bug.php?id=51689&edit=1
Req #60850 [Com]: Built in web server does not set $_SERVER['SCRIPT_FILENAME'] when using router
Edit report at https://bugs.php.net/bug.php?id=60850&edit=1 ID: 60850 Comment by: sam dot e dot giles at googlemail dot com Reported by:dave dot marshall at atstsolutions dot co dot uk Summary:Built in web server does not set $_SERVER['SCRIPT_FILENAME'] when using router Status: Open Type: Feature/Change Request Package:Built-in web server Operating System: Linux/Ubuntu 11.10 PHP Version:5.4SVN-2012-01-23 (snap) Block user comment: N Private report: N New Comment: Sorry for the multiple comments.. I see what laruence was saying now about the script that has been routed to. After playing around some more, I see what is meant by this. If the router returns false, then the resource is served as is, and, if it is a PHP script, the $_SERVER['SCRIPT_FILENAME'] is set to the resource when the dispatched script is executed. However, if we set the server variable as the router, SCRIPT_FILENAME variable will always point to the router. So if you were to have the following code in your router: ~/Downloads/php5.4-201201231230/sapi/cli/php -S localhost:8000 router.php Fetch the root url, NULL returned > curl localhost:8000 NULL Given that this variable is documented, I'd expect it to be string(29) "/home/davem/temp_ws/router.php" Touching a file called index.php, seems to trick the webserver in to thinking it's done a path translation for the root url > touch index.php > curl localhost:8000 string(29) "/home/davem/temp_ws/index.php" Test script: --- router.php https://bugs.php.net/bug.php?id=60850&edit=1
Bug #61325 [Opn->Fbk]: FastCGI keeps dieing
Edit report at https://bugs.php.net/bug.php?id=61325&edit=1 ID: 61325 Updated by: larue...@php.net Reported by:Alastair at adewra dot com Summary:FastCGI keeps dieing -Status: Open +Status: Feedback Type: Bug Package:CGI/CLI related Operating System: CentOS PHP Version:5.4.0 Block user comment: N Private report: N New Comment: Hi, plz look into the pwd of php-cgi, check is there any core dump file generated? if find one, plz paste the bt here. thanks Previous Comments: [2012-03-08 12:36:07] Alastair at adewra dot com Description: Currently running Lighttpd which returns a 500 - Internal Server Error with this log: 2012-03-08 12:26:32: (mod_fastcgi.c.2568) unexpected end-of-file (perhaps the fastcgi process died): pid: 10734 socket: unix:/tmp/php.socket10726-3 2012-03-08 12:26:32: (mod_fastcgi.c.3356) response not received, request sent: 879 on socket: unix:/tmp/php.socket10726-3 for /index.php?, closing connection php -v: PHP 5.4.0 (cli) (built: Mar 7 2012 20:14:12) Copyright (c) 1997-2012 The PHP Group Zend Engine v2.4.0, Copyright (c) 1998-2012 Zend Technologies php-cgi -v: PHP Warning: Unknown: function '1' not found or invalid function name in Unknown on line 0 PHP 5.4.0 (cgi-fcgi) (built: Mar 7 2012 20:14:29) Copyright (c) 1997-2012 The PHP Group Zend Engine v2.4.0, Copyright (c) 1998-2012 Zend Technologies configure line: ./configure --with-config-file-path=/etc --with-config-file-scan-dir=/etc/php.d - -with-libdir=lib64 --with-mysql --with-mysqli --with-zlib --with-curl --with- mcrypt --enable-cgi If there is anything else I can do to help I will. Sorry, this is my first bug report. -- Edit this bug report at https://bugs.php.net/bug.php?id=61325&edit=1
Req #60850 [Com]: Built in web server does not set $_SERVER['SCRIPT_FILENAME'] when using router
Edit report at https://bugs.php.net/bug.php?id=60850&edit=1 ID: 60850 Comment by: sam dot e dot giles at googlemail dot com Reported by:dave dot marshall at atstsolutions dot co dot uk Summary:Built in web server does not set $_SERVER['SCRIPT_FILENAME'] when using router Status: Open Type: Feature/Change Request Package:Built-in web server Operating System: Linux/Ubuntu 11.10 PHP Version:5.4SVN-2012-01-23 (snap) Block user comment: N Private report: N New Comment: Added a patch to add this functionality. Previous Comments: [2012-03-09 01:31:15] sam dot e dot giles at googlemail dot com I'm split on this issue. On one hand for consistency I think that the $_SERVER['SCRIPT_FILENAME'] should be set in the router script. On the other hand, this is meant to be a test server NOT a production server, and the router script should simply be used to route, or rewrite URL's to another script, i.e. The router script shouldn't be used in production as is. Either way the documentation should reflect this. However I personally, after much thought think that $_SERVER['SCRIPT_FILENAME'] should be set, purely for consistency, after all, it is the filename of the running script. [2012-01-24 10:15:34] dave dot marshall at atstsolutions dot co dot uk I appreciate that, but that assumes the router will route to another script on disk, rather than loading the required code and generating a response like most of the MVC frameworks do. [2012-01-24 02:56:18] larue...@php.net router is a especially script, if we set this as the script_name, what about the script which router routed to? [2012-01-23 13:45:31] dave dot marshall at atstsolutions dot co dot uk Description: Nothing special done when compiling, just --configure and then make. If the webserver couldn't do any path translation, $_SERVER['SCRIPT_FILENAME'] is not populated. If this is desired behaviour, perhaps the documentation should be updated, as existing software will rely on it. Given the code below in router.php, and starting the web server with a router > ~/Downloads/php5.4-201201231230/sapi/cli/php -S localhost:8000 router.php Fetch the root url, NULL returned > curl localhost:8000 NULL Given that this variable is documented, I'd expect it to be string(29) "/home/davem/temp_ws/router.php" Touching a file called index.php, seems to trick the webserver in to thinking it's done a path translation for the root url > touch index.php > curl localhost:8000 string(29) "/home/davem/temp_ws/index.php" Test script: --- router.php https://bugs.php.net/bug.php?id=60850&edit=1
Req #60850 [Com]: Built in web server does not set $_SERVER['SCRIPT_FILENAME'] when using router
Edit report at https://bugs.php.net/bug.php?id=60850&edit=1 ID: 60850 Comment by: sam dot e dot giles at googlemail dot com Reported by:dave dot marshall at atstsolutions dot co dot uk Summary:Built in web server does not set $_SERVER['SCRIPT_FILENAME'] when using router Status: Open Type: Feature/Change Request Package:Built-in web server Operating System: Linux/Ubuntu 11.10 PHP Version:5.4SVN-2012-01-23 (snap) Block user comment: N Private report: N New Comment: I'm split on this issue. On one hand for consistency I think that the $_SERVER['SCRIPT_FILENAME'] should be set in the router script. On the other hand, this is meant to be a test server NOT a production server, and the router script should simply be used to route, or rewrite URL's to another script, i.e. The router script shouldn't be used in production as is. Either way the documentation should reflect this. However I personally, after much thought think that $_SERVER['SCRIPT_FILENAME'] should be set, purely for consistency, after all, it is the filename of the running script. Previous Comments: [2012-01-24 10:15:34] dave dot marshall at atstsolutions dot co dot uk I appreciate that, but that assumes the router will route to another script on disk, rather than loading the required code and generating a response like most of the MVC frameworks do. [2012-01-24 02:56:18] larue...@php.net router is a especially script, if we set this as the script_name, what about the script which router routed to? [2012-01-23 13:45:31] dave dot marshall at atstsolutions dot co dot uk Description: Nothing special done when compiling, just --configure and then make. If the webserver couldn't do any path translation, $_SERVER['SCRIPT_FILENAME'] is not populated. If this is desired behaviour, perhaps the documentation should be updated, as existing software will rely on it. Given the code below in router.php, and starting the web server with a router > ~/Downloads/php5.4-201201231230/sapi/cli/php -S localhost:8000 router.php Fetch the root url, NULL returned > curl localhost:8000 NULL Given that this variable is documented, I'd expect it to be string(29) "/home/davem/temp_ws/router.php" Touching a file called index.php, seems to trick the webserver in to thinking it's done a path translation for the root url > touch index.php > curl localhost:8000 string(29) "/home/davem/temp_ws/index.php" Test script: --- router.php https://bugs.php.net/bug.php?id=60850&edit=1
Bug #55334 [Com]: MySQLi make mod_php crash on stress test
Edit report at https://bugs.php.net/bug.php?id=55334&edit=1 ID: 55334 Comment by: mattfic...@php.net Reported by:bruno at chalopin dot fr Summary:MySQLi make mod_php crash on stress test Status: Assigned Type: Bug Package:MySQLi related Operating System: Windows 2008r2 x64 PHP Version:5.3.7RC4 Assigned To:mattficken Block user comment: N Private report: N New Comment: Using apache bench locally, I can reproduce this bug on php 5.3.10 and php 5.4.0 using just mysqli. Previous Comments: [2012-03-08 13:08:19] johan...@php.net 13:58 <@johannes> Pierre: can you check 5.3 in your stress tests regarding 55334? On Linux and Solaris I can't hit it in threaded context anymore. 5.4/trunk seems to be fixed by dmitry's property refactoring work (svn r299692) 14:05 <@Pierre> johannes, add a comment to the bug and assign it to matt. [2012-03-08 12:55:25] johan...@php.net Seems like this was a bug from very old times in mysqli. I've applied a fix to PHP_5_3 and couldn't trigger an issue anymore with lots of concurrency over a longer period. A fix for 5.4 and trunk is not needed as the code had been refactored before. Please run your tests, too. [2012-03-08 12:52:03] johan...@php.net Automatic comment from SVN on behalf of johannes Revision: http://svn.php.net/viewvc/?view=revision&revision=324022 Log: Use correct property ctor, should fix threading issue in bug #55334 # The code was refactored in 5_4/trunk, no need to merge [2012-01-19 07:40:46] ninzya at inbox dot lv Got apache crashing due to MySQLi as well. Here's the bug report: https://bugs.php.net/bug.php?id=55334 [2011-10-21 14:47:09] doug at sevone dot com I have been able to reproduce a similar (if not the same) crash by this SIMPLER script: On another machine, I have about 12 threads doing GET requests to that page simultaneously. I usually see a crash after about 1-2 seconds. As far as I can tell, this is a "mysqli" issue only (involving thread-safety). If I disable mysqlnd, then I still see the same problem. I see this on MySQL 5.5 and 5.1. However, the MySQL version should NOT matter, since I can reproduce the problem without EVER connecting to a MySQL box, and since it crashes using mysqlnd. OS: gentoo (x86_64) Apache: www-servers/apache-2.2.14-r1 Apache: www-servers/apache-2.2.21 PHP: dev-lang/php-5.3.6 PHP: dev-lang/php-5.3.8 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 https://bugs.php.net/bug.php?id=55334 -- Edit this bug report at https://bugs.php.net/bug.php?id=55334&edit=1
Bug #60758 [Nab->Asn]: require() crashes Apache
Edit report at https://bugs.php.net/bug.php?id=60758&edit=1 ID: 60758 Updated by: paj...@php.net Reported by:bugzilla33 at gmail dot com Summary:require() crashes Apache -Status: Not a bug +Status: Assigned Type: Bug Package:Reproducible crash Operating System: Windows PHP Version:5.4.0RC5 -Assigned To: +Assigned To:dmitry Block user comment: N Private report: N New Comment: hi Dmitry, Seems that we have it back :P Previous Comments: [2012-03-08 18:53:57] mmoreno at pobox dot com I've confirmed this problem has NOT been fixed using this snapshot (2012-03-08): http://windows.php.net/downloads/snaps/php-5.3/r324022/php-5.3-ts-windows-vc9-x86- r324022.zip [2012-03-07 20:55:41] paj...@php.net It is already fixed in svn, use a snapshot if you like to confirm it. 5.3.11 will have the fix (5.4.0 has it). [2012-03-07 20:50:41] chris at deskpro dot com I can also report this problem still exists in PHP 5.3.10 - Windows 7 64 bit with distro from http://www.wampserver.com/en/ - arises when loading Symfony: https://github.com/symfony/symfony/issues/3216 [2012-02-08 17:30:04] mmoreno at pobox dot com I too am experiencing this same problem on 5.3.10 running on Windows 2008 SP2. I have also confirmed that this is crashing when trying to include() a file that happens to be exactly 4096 bytes. Can you explain how this is "has already been fixed" and/or "is a different issue"? Am I missing something? Unfortunately, I don't have the means to build and test a snapshot. Full Call Stack Function Arg 1 Arg 2 Arg 3 Arg 4 Source php5ts!lex_scan+d12 0363e348 027adb48 027adb48 0363e374 c:\php-sdk\snap_5_3\vc9\x86\php-5.3.10-ts\zend\zend_language_scanner.c @ 2507 + 12 php5ts!zendlex+4e 0363e340 027adb48 06826510 027adb48 c:\php-sdk\snap_5_3\vc9\x86\php-5.3.10-ts\zend\zend_compile.c @ 4975 + b php5ts!zendparse+1d4 027adb48 06826510 0002 0040 c:\php-sdk\snap_5_3\vc9\x86\php-5.3.10-ts\zend\zend_language_parser.c @ 3285 + b php5ts!compile_file+e4 0363f99c 0008 027adb00 027adb48 c:\php-sdk\snap_5_3\vc9\x86\php-5.3.10-ts\zend\zend_language_scanner.l @ 365 php5ts!phar_compile_file+1e6 0363f99c 0008 027adb48 027adb48 c:\php-sdk\snap_5_3\vc9\x86\php-5.3.10-ts\ext\phar\phar.c @ 3393 + 1b php5ts!ZEND_INCLUDE_OR_EVAL_SPEC_CV_HANDLER+251 040d6eb8 0363fab4 027adb48 03b70124 c:\php-sdk\snap_5_3\vc9\x86\php-5.3.10-ts\zend\zend_vm_execute.h @ 22510 php5ts!execute+2e8 041e7fb0 027adb01 027adb48 052690a0 c:\php-sdk\snap_5_3\vc9\x86\php-5.3.10-ts\zend\zend_vm_execute.h @ 107 + a php5ts!zend_call_function+862 0363faa0 03b70280 c:\php-sdk\snap_5_3\vc9\x86\php-5.3.10-ts\zend\zend_execute_api.c @ 969 + 1b php5ts!zif_call_user_func_array+63 0002 06623018 c:\php-sdk\snap_5_3\vc9\x86\php-5.3.10-ts\ext\standard\basic_functions.c @ 4803 + 18 php5ts!zend_do_fcall_common_helper_SPEC+920 03b70280 027adb00 027adb48 03b70280 c:\php-sdk\snap_5_3\vc9\x86\php-5.3.10-ts\zend\zend_vm_execute.h @ 320 + 41 php5ts!ZEND_DO_FCALL_SPEC_CONST_HANDLER+11a 027adb48 0363fbb8 0363fe44 c:\php-sdk\snap_5_3\vc9\x86\php-5.3.10-ts\zend\zend_vm_execute.h @ 1640 + e php5ts!execute+2e8 03b3e5e0 027adb00 027adb48 c:\php-sdk\snap_5_3\vc9\x86\php-5.3.10-ts\zend\zend_vm_execute.h @ 107 + a php5ts!zend_execute_scripts+fe 0008 027adb48 0003 c:\php-sdk\snap_5_3\vc9\x86\php-5.3.10-ts\zend\zend.c @ 1237 php5ts!php_execute_script+24c 0363fe44 027adb48 0005 018a416c c:\php-sdk\snap_5_3\vc9\x86\php-5.3.10-ts\main\main.c @ 2308 + 12 php5apache2_2!php_handler+634 0268f050 0268f050 018a4ce0 6eecd540 c:\php-sdk\snap_5_3\vc9\x86\php-5.3.10-ts\sapi\apache2handler\sapi_apache2.c @ 669 + e libhttpd!ap_run_handler+25 [2012-02-06 08:11:42] hannes at dorn dot cc Ups, sorry, 4096 byte require bug still exists in 5.3.10 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 https://bugs.php.net/bug.php?id=60758 -- Edit this bug report at https://bugs.php.net/bug.php?id=60758&edit=1
Bug #51775 [Csd]: Chunked response parsing error
Edit report at https://bugs.php.net/bug.php?id=51775&edit=1 ID: 51775 User updated by:vic at zymsys dot com Reported by:vic at zymsys dot com Summary:Chunked response parsing error Status: Closed Type: Bug Package:SOAP related Operating System: CentOS 4.8 PHP Version:5.3SVN-2010-05-09 (snap) Assigned To:dmitry Block user comment: N Private report: N New Comment: Wow, what a blast from the past. You the man Ilia! I'd love to hear what was really involved in fixing this, maybe if you're at another GTAPHP meetup sometime. Thanks! Previous Comments: [2012-03-08 20:14:26] il...@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/. For Windows: http://windows.php.net/snapshots/ Thank you for the report, and for helping us make PHP better. [2012-03-08 20:14:18] il...@php.net Automatic comment from SVN on behalf of iliaa Revision: http://svn.php.net/viewvc/?view=revision&revision=324027 Log: Fixed bug #60842, #51775 (Chunked response parsing error when chunksize length line is > 10 bytes). [2010-05-31 17:52:22] vic at zymsys dot com Do you suggest we re-assign this but to someone who handles the php_stream_gets() function then? I can try to create a test case for this, but I'll have a learning curve to overcome, and I won't have enough time for a while to dedicate to that. Digging deeper, php_stream_gets() is really _php_stream_get_line(), and _php_stream_get_line() calls php_stream_locate_eol() to get a pointer to the end of line byte. It looks like php_stream_locate_eol() tries to be clever about detecting Mac or Unix EOL, and that it treats CR/LF pairs as Unix, so it would return the CR as part of the string. So for it to act as it is in this case, it must be somehow detecting this as containing old Mac style line breaks, and stopping at the CR. Here's a hex dump of what comes in from the start of the HTTP response to the chunk where it gets thrown off. It looks like consistent CR/LF pairs to me so I'm not sure why it would think this response was using just CR EOL markers. I'll have to see if I can get this running under gdb to see why the stream thinks it is Mac style (CR) EOL markers. 0760 00 00 01 01 08 0a 01 17 ed ec c0 12 e4 f1 48 54 |..HT| 0770 54 50 2f 31 2e 31 20 32 30 30 20 4f 4b 0d 0a 43 |TP/1.1 200 OK..C| 0780 6f 6e 6e 65 63 74 69 6f 6e 3a 20 6b 65 65 70 2d |onnection: keep-| 0790 61 6c 69 76 65 0d 0a 54 72 61 6e 73 66 65 72 2d |alive..Transfer-| 07a0 45 6e 63 6f 64 69 6e 67 3a 20 63 68 75 6e 6b 65 |Encoding: chunke| 07b0 64 0d 0a 56 69 61 3a 20 31 2e 31 20 42 50 4c 30 |d..Via: 1.1 BPL0| 07c0 34 32 20 28 56 6f 72 64 65 6c 29 2c 20 31 2e 31 |42 (Vordel), 1.1| 07d0 20 65 70 6c 32 30 33 20 28 56 6f 72 64 65 6c 29 | epl203 (Vordel)| 07e0 0d 0a 44 61 74 65 3a 20 46 72 69 2c 20 30 37 20 |..Date: Fri, 07 | 07f0 4d 61 79 20 32 30 31 30 20 32 30 3a 30 34 3a 32 |May 2010 20:04:2| 0800 34 20 47 4d 54 0d 0a 53 4f 41 50 41 63 74 69 6f |4 GMT..SOAPActio| 0810 6e 3a 20 22 22 0d 0a 58 2d 50 6f 77 65 72 65 64 |n: ""..X-Powered| 0820 2d 42 79 3a 20 53 65 72 76 6c 65 74 2f 32 2e 35 |-By: Servlet/2.5| 0830 20 4a 53 50 2f 32 2e 31 0d 0a 43 6f 6e 74 65 6e | JSP/2.1..Conten| 0840 74 2d 54 79 70 65 3a 20 74 65 78 74 2f 78 6d 6c |t-Type: text/xml| 0850 3b 20 63 68 61 72 73 65 74 3d 22 75 74 66 2d 38 |; charset="utf-8| 0860 22 0d 0a 0d 0a 30 30 30 30 30 31 62 63 0d 0a 3c |"01bc..<| 0870 65 6e 76 3a 45 6e 76 65 6c 6f 70 65 20 78 6d 6c |env:Envelope xml| [2010-05-28 11:35:04] dmi...@php.net I can't reproduce the issue. Anyway php_stream_gets() must make its work proper and ext/soap doesn't have to care about its mistakes. Especially because '\n' may be a valid character in data stream. [2010-05-09 06:07:09] vic at zymsys dot com Description: I was getting an error from a SoapClient call: "Error Fetching http body, No Content-Length, connection closed or chunked data". Thing was I couldn't see any problem with the HTTP response. I tracked the problem down to the get_http_body function in ext/soap/php_http.c, where it reads the chunk size using php_stream_gets(). That's returning the chunk size plus the CR (0d) but leaving the LF (0a) unread. Then the unread LF gets read with HTTP chunk, and the attempt to re
Bug #60842 [Opn->Csd]: CR+LF bug on chunk_size
Edit report at https://bugs.php.net/bug.php?id=60842&edit=1
ID: 60842
Updated by: il...@php.net
Reported by:120122 at jxs dot nl
Summary:CR+LF bug on chunk_size
-Status: Open
+Status: Closed
Type: Bug
Package:SOAP related
Operating System: any
PHP Version:5.3.9
-Assigned To:
+Assigned To:iliaa
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/.
For Windows:
http://windows.php.net/snapshots/
Thank you for the report, and for helping us make PHP better.
Previous Comments:
[2012-03-08 20:14:17] il...@php.net
Automatic comment from SVN on behalf of iliaa
Revision: http://svn.php.net/viewvc/?view=revision&revision=324027
Log: Fixed bug #60842, #51775 (Chunked response parsing error when chunksize
length line is > 10 bytes).
[2012-01-22 22:24:05] 120122 at jxs dot nl
Description:
The soap extension has a bug in parsing the chunk_size of messages with
Transfer-Encoding: chunked. When the other end is sending CR+LF (a Windows
server), only the CR is read to the chunk_size variable, while the LF is
prepended to the message body. In that case, the actual XML message is one byte
short at the end.
This issue was reported before ( https://bugs.php.net/bug.php?id=51775 ), but
never fixed.
Test script:
---
"http://webservices-acc.cibg.nl/Ribiz/Openbaar.asmx";,
"uri" => "http://services.cibg.nl/ExternalUser/ListHcpApprox";,
'trace'=>1
)
);
$message = new stdClass();
$message->WebSite = 'Ribiz';
$message->RegistrationNumber = '59023925501';
$x=$client->ListHcpApprox($message);
print_r($x);
Expected result:
stdClass Object
(
[ListHcpApprox] => stdClass Object
(
[ListHcpApprox] => stdClass Object
(
[HcpNumber] => 239255
[BirthSurname] => Smalen
[Prefix] => de
...
Actual result:
--
PHP Fatal error: Uncaught SoapFault exception: [HTTP] Error Fetching http
body, No Content-Length, connection closed or chunked data in
/home/jxs.nl/a.php:13
Stack trace:
#0 [internal function]: SoapClient->__doRequest('http://webservi...', 'http://services...', 1, 0)
#1 /home/jxs.nl/soap/a.php(13): SoapClient->__call('ListHcpApprox', Array)
#2 /home/jxs.nl/soap/a.php(13): SoapClient->ListHcpApprox(Object(stdClass))
#3 {main}
thrown in /home/jxs.nl/soap/a.php on line 13
--
Edit this bug report at https://bugs.php.net/bug.php?id=60842&edit=1
Bug #51775 [Fbk->Csd]: Chunked response parsing error
Edit report at https://bugs.php.net/bug.php?id=51775&edit=1 ID: 51775 Updated by: il...@php.net Reported by:vic at zymsys dot com Summary:Chunked response parsing error -Status: Feedback +Status: Closed Type: Bug Package:SOAP related Operating System: CentOS 4.8 PHP Version:5.3SVN-2010-05-09 (snap) Assigned To:dmitry 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/. For Windows: http://windows.php.net/snapshots/ Thank you for the report, and for helping us make PHP better. Previous Comments: [2012-03-08 20:14:18] il...@php.net Automatic comment from SVN on behalf of iliaa Revision: http://svn.php.net/viewvc/?view=revision&revision=324027 Log: Fixed bug #60842, #51775 (Chunked response parsing error when chunksize length line is > 10 bytes). [2010-05-31 17:52:22] vic at zymsys dot com Do you suggest we re-assign this but to someone who handles the php_stream_gets() function then? I can try to create a test case for this, but I'll have a learning curve to overcome, and I won't have enough time for a while to dedicate to that. Digging deeper, php_stream_gets() is really _php_stream_get_line(), and _php_stream_get_line() calls php_stream_locate_eol() to get a pointer to the end of line byte. It looks like php_stream_locate_eol() tries to be clever about detecting Mac or Unix EOL, and that it treats CR/LF pairs as Unix, so it would return the CR as part of the string. So for it to act as it is in this case, it must be somehow detecting this as containing old Mac style line breaks, and stopping at the CR. Here's a hex dump of what comes in from the start of the HTTP response to the chunk where it gets thrown off. It looks like consistent CR/LF pairs to me so I'm not sure why it would think this response was using just CR EOL markers. I'll have to see if I can get this running under gdb to see why the stream thinks it is Mac style (CR) EOL markers. 0760 00 00 01 01 08 0a 01 17 ed ec c0 12 e4 f1 48 54 |..HT| 0770 54 50 2f 31 2e 31 20 32 30 30 20 4f 4b 0d 0a 43 |TP/1.1 200 OK..C| 0780 6f 6e 6e 65 63 74 69 6f 6e 3a 20 6b 65 65 70 2d |onnection: keep-| 0790 61 6c 69 76 65 0d 0a 54 72 61 6e 73 66 65 72 2d |alive..Transfer-| 07a0 45 6e 63 6f 64 69 6e 67 3a 20 63 68 75 6e 6b 65 |Encoding: chunke| 07b0 64 0d 0a 56 69 61 3a 20 31 2e 31 20 42 50 4c 30 |d..Via: 1.1 BPL0| 07c0 34 32 20 28 56 6f 72 64 65 6c 29 2c 20 31 2e 31 |42 (Vordel), 1.1| 07d0 20 65 70 6c 32 30 33 20 28 56 6f 72 64 65 6c 29 | epl203 (Vordel)| 07e0 0d 0a 44 61 74 65 3a 20 46 72 69 2c 20 30 37 20 |..Date: Fri, 07 | 07f0 4d 61 79 20 32 30 31 30 20 32 30 3a 30 34 3a 32 |May 2010 20:04:2| 0800 34 20 47 4d 54 0d 0a 53 4f 41 50 41 63 74 69 6f |4 GMT..SOAPActio| 0810 6e 3a 20 22 22 0d 0a 58 2d 50 6f 77 65 72 65 64 |n: ""..X-Powered| 0820 2d 42 79 3a 20 53 65 72 76 6c 65 74 2f 32 2e 35 |-By: Servlet/2.5| 0830 20 4a 53 50 2f 32 2e 31 0d 0a 43 6f 6e 74 65 6e | JSP/2.1..Conten| 0840 74 2d 54 79 70 65 3a 20 74 65 78 74 2f 78 6d 6c |t-Type: text/xml| 0850 3b 20 63 68 61 72 73 65 74 3d 22 75 74 66 2d 38 |; charset="utf-8| 0860 22 0d 0a 0d 0a 30 30 30 30 30 31 62 63 0d 0a 3c |"01bc..<| 0870 65 6e 76 3a 45 6e 76 65 6c 6f 70 65 20 78 6d 6c |env:Envelope xml| [2010-05-28 11:35:04] dmi...@php.net I can't reproduce the issue. Anyway php_stream_gets() must make its work proper and ext/soap doesn't have to care about its mistakes. Especially because '\n' may be a valid character in data stream. [2010-05-09 06:07:09] vic at zymsys dot com Description: I was getting an error from a SoapClient call: "Error Fetching http body, No Content-Length, connection closed or chunked data". Thing was I couldn't see any problem with the HTTP response. I tracked the problem down to the get_http_body function in ext/soap/php_http.c, where it reads the chunk size using php_stream_gets(). That's returning the chunk size plus the CR (0d) but leaving the LF (0a) unread. Then the unread LF gets read with HTTP chunk, and the attempt to read the next chunk size starts with the last character of the HTTP chunk, since it's behind one thanks to the unread LF. Here's a chunk of the response that throws it off, with the chunk size (01bc) in the middle, surrounded by CR/LF pairs. 0850 3b
Bug #60997 [Opn->Nab]: getopt() parses optional values incorrectly
Edit report at https://bugs.php.net/bug.php?id=60997&edit=1
ID: 60997
Updated by: il...@php.net
Reported by:eric at wepay dot com
Summary:getopt() parses optional values incorrectly
-Status: Open
+Status: Not a bug
Type: Bug
Package:CGI/CLI related
Operating System: Linux CentOS
PHP Version:5.3.10
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
Previous Comments:
[2012-02-07 03:45:22] carloschilazo at gmail dot com
Documentation also states:
Note: Optional values do not accept " " (space) as a separator.
[2012-02-06 23:51:51] eric at wepay dot com
Description:
If a CLI argument is passed with leading whitespace, the value is not picked up
by
getopt() if specified as an optional value (with two colons). This is contrary
to
the documentation, which states, "Option values are the first argument after
the
string. It does not matter if a value has leading white space or not."
Test script:
---
$ ./test.php -v2 asdf # behaves as expected
$ ./test.php -v=2 asdf # behaves as expected
$ ./test.php -v 2 asdf # problem case, shown in actual result
Expected result:
array(1) {
["v"]=>
bool(false)
}
array(1) {
["v"]=>
string(1) "2"
}
array(1) {
["v"]=>
string(1) "2"
}
Actual result:
--
array(1) {
["v"]=>
bool(false)
}
array(1) {
["v"]=>
string(1) "2"
}
array(1) {
["v"]=>
bool(false)
}
--
Edit this bug report at https://bugs.php.net/bug.php?id=60997&edit=1
Bug #60758 [Com]: require() crashes Apache
Edit report at https://bugs.php.net/bug.php?id=60758&edit=1 ID: 60758 Comment by: mmoreno at pobox dot com Reported by:bugzilla33 at gmail dot com Summary:require() crashes Apache Status: Not a bug Type: Bug Package:Reproducible crash Operating System: Windows PHP Version:5.4.0RC5 Block user comment: N Private report: N New Comment: I've confirmed this problem has NOT been fixed using this snapshot (2012-03-08): http://windows.php.net/downloads/snaps/php-5.3/r324022/php-5.3-ts-windows-vc9-x86- r324022.zip Previous Comments: [2012-03-07 20:55:41] paj...@php.net It is already fixed in svn, use a snapshot if you like to confirm it. 5.3.11 will have the fix (5.4.0 has it). [2012-03-07 20:50:41] chris at deskpro dot com I can also report this problem still exists in PHP 5.3.10 - Windows 7 64 bit with distro from http://www.wampserver.com/en/ - arises when loading Symfony: https://github.com/symfony/symfony/issues/3216 [2012-02-08 17:30:04] mmoreno at pobox dot com I too am experiencing this same problem on 5.3.10 running on Windows 2008 SP2. I have also confirmed that this is crashing when trying to include() a file that happens to be exactly 4096 bytes. Can you explain how this is "has already been fixed" and/or "is a different issue"? Am I missing something? Unfortunately, I don't have the means to build and test a snapshot. Full Call Stack Function Arg 1 Arg 2 Arg 3 Arg 4 Source php5ts!lex_scan+d12 0363e348 027adb48 027adb48 0363e374 c:\php-sdk\snap_5_3\vc9\x86\php-5.3.10-ts\zend\zend_language_scanner.c @ 2507 + 12 php5ts!zendlex+4e 0363e340 027adb48 06826510 027adb48 c:\php-sdk\snap_5_3\vc9\x86\php-5.3.10-ts\zend\zend_compile.c @ 4975 + b php5ts!zendparse+1d4 027adb48 06826510 0002 0040 c:\php-sdk\snap_5_3\vc9\x86\php-5.3.10-ts\zend\zend_language_parser.c @ 3285 + b php5ts!compile_file+e4 0363f99c 0008 027adb00 027adb48 c:\php-sdk\snap_5_3\vc9\x86\php-5.3.10-ts\zend\zend_language_scanner.l @ 365 php5ts!phar_compile_file+1e6 0363f99c 0008 027adb48 027adb48 c:\php-sdk\snap_5_3\vc9\x86\php-5.3.10-ts\ext\phar\phar.c @ 3393 + 1b php5ts!ZEND_INCLUDE_OR_EVAL_SPEC_CV_HANDLER+251 040d6eb8 0363fab4 027adb48 03b70124 c:\php-sdk\snap_5_3\vc9\x86\php-5.3.10-ts\zend\zend_vm_execute.h @ 22510 php5ts!execute+2e8 041e7fb0 027adb01 027adb48 052690a0 c:\php-sdk\snap_5_3\vc9\x86\php-5.3.10-ts\zend\zend_vm_execute.h @ 107 + a php5ts!zend_call_function+862 0363faa0 03b70280 c:\php-sdk\snap_5_3\vc9\x86\php-5.3.10-ts\zend\zend_execute_api.c @ 969 + 1b php5ts!zif_call_user_func_array+63 0002 06623018 c:\php-sdk\snap_5_3\vc9\x86\php-5.3.10-ts\ext\standard\basic_functions.c @ 4803 + 18 php5ts!zend_do_fcall_common_helper_SPEC+920 03b70280 027adb00 027adb48 03b70280 c:\php-sdk\snap_5_3\vc9\x86\php-5.3.10-ts\zend\zend_vm_execute.h @ 320 + 41 php5ts!ZEND_DO_FCALL_SPEC_CONST_HANDLER+11a 027adb48 0363fbb8 0363fe44 c:\php-sdk\snap_5_3\vc9\x86\php-5.3.10-ts\zend\zend_vm_execute.h @ 1640 + e php5ts!execute+2e8 03b3e5e0 027adb00 027adb48 c:\php-sdk\snap_5_3\vc9\x86\php-5.3.10-ts\zend\zend_vm_execute.h @ 107 + a php5ts!zend_execute_scripts+fe 0008 027adb48 0003 c:\php-sdk\snap_5_3\vc9\x86\php-5.3.10-ts\zend\zend.c @ 1237 php5ts!php_execute_script+24c 0363fe44 027adb48 0005 018a416c c:\php-sdk\snap_5_3\vc9\x86\php-5.3.10-ts\main\main.c @ 2308 + 12 php5apache2_2!php_handler+634 0268f050 0268f050 018a4ce0 6eecd540 c:\php-sdk\snap_5_3\vc9\x86\php-5.3.10-ts\sapi\apache2handler\sapi_apache2.c @ 669 + e libhttpd!ap_run_handler+25 [2012-02-06 08:11:42] hannes at dorn dot cc Ups, sorry, 4096 byte require bug still exists in 5.3.10 [2012-02-06 08:06:51] hannes at dorn dot cc FYI I had this problem in 5.3.9, but it is fixed in 5.3.10. 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 https://bugs.php.net/bug.php?id=60758 -- Edit this bug report at https://bugs.php.net/bug.php?id=60758&edit=1
Bug #61166 [Com]: PHP crashing (Drupal site)
Edit report at https://bugs.php.net/bug.php?id=61166&edit=1 ID: 61166 Comment by: mmoreno at pobox dot com Reported by:guaycuru at gmail dot com Summary:PHP crashing (Drupal site) Status: Feedback Type: Bug Package:Reproducible crash Operating System: Windows 7 x64 PHP Version:5.3SVN-2012-02-22 (snap) Block user comment: N Private report: N New Comment: I've confirmed this problem has NOT been fixed using this snapshot (2012-03-08): http://windows.php.net/downloads/snaps/php-5.3/r324022/php-5.3-ts-windows-vc9-x86- r324022.zip Previous Comments: [2012-03-07 10:36:35] paj...@php.net Please try using this snapshot: http://snaps.php.net/php5.3-latest.tar.gz For Windows: http://windows.php.net/snapshots/ [2012-02-23 17:55:28] guaycuru at gmail dot com Yep, that's exactly it! The file was 20480 bytes. Added one blank space and the crash was gone! It's definetely not fixed! =\ Thanks a lot for clearing this up! [2012-02-23 17:37:03] mmoreno at pobox dot com This was crashing Drupal 7 for me too. I bet you're encountering the 4096 byte bug referenced in bugs 60758 and 60998. The responses have been that it's either fixed in SVN or not a bug so I'm confused about the status since recent snapshots are still affected. Seems to only affect Windows. WORKAROUND: Find all Drupal files that are exactly 4096 bytes or a multiple (e.g. 8192, 12288) and edit them slightly by adding a blank line or a comment in order to change the file size. Hope this helps. [2012-02-22 19:12:33] guaycuru at gmail dot com I tried Apache 2.2.21 and 2.4.1, both downloaded from Apache Lounge. Anyway the crash happens using PHP CLI, so it's not apache related. I'm using Drupal 7 [2012-02-22 18:59:25] mattfic...@php.net Thank you for helping to make PHP better. What version of Apache are you using? Where did you download it from? What version of Drupal are you using? 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 https://bugs.php.net/bug.php?id=61166 -- Edit this bug report at https://bugs.php.net/bug.php?id=61166&edit=1
Bug #61307 [Nab]: hash-tiger generates a different value between 5.3/5.4
Edit report at https://bugs.php.net/bug.php?id=61307&edit=1
ID: 61307
Updated by: m...@php.net
Reported by:andres at phalconphp dot com
Summary:hash-tiger generates a different value between
5.3/5.4
Status: Not a bug
Type: Bug
Package:hash related
Operating System: Irrelevant
PHP Version:5.4.0
Block user comment: N
Private report: N
New Comment:
Sorry folks, here's a one-liner to re-create pre-PHP-5.4 hashes:
implode("", array_map("bin2hex", array_map("strrev",
str_split(hash("tiger192,3", $input, true), 8;
Truncate the result to the length you need (128,160,192 bits). Make sure every
array value is 16 hex digits long or else lpad it with literal 0s.
If you used 192 bit tiger, you can use the following one-liner to create
correct
hashes from the wrong ones:
implode("", array_map("bin2hex", array_map("strrev", array_map("hex2bin",
str_split($wronghash,16);
Previous Comments:
[2012-03-07 19:40:33] me at ktamura dot com
Thanks mike. I should have read the commit message first. Sorry for the false
allegation.
[2012-03-07 18:15:40] ras...@php.net
Yeah, I think we need to come up with a way to support both or else it leaves
people without an easy way to fix those hashes. Technically I guess you can
reconstruct it from the raw by flipping the bytes, but that is rather error-
prone.
[2012-03-07 16:22:17] andres at phalconphp dot com
This is quite unfortunate, We have thousand of passwords stored in the wrong
hash order. It looks like we have to keep PHP 5.3 for a long time.
[2012-03-07 10:55:03] m...@php.net
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
See changelog in documentation.
[2012-03-06 23:58:10] me at ktamura dot com
This is a bug in ext/hash/hash_tiger.c It looks like there was a mistake during
refactoring. I am attaching a patch.
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
https://bugs.php.net/bug.php?id=61307
--
Edit this bug report at https://bugs.php.net/bug.php?id=61307&edit=1
Bug #61328 [Opn->Fbk]: segmentation fault while traversing big arrays with foreach
Edit report at https://bugs.php.net/bug.php?id=61328&edit=1
ID: 61328
Updated by: cataphr...@php.net
Reported by:anil at saog dot net
Summary:segmentation fault while traversing big arrays with
foreach
-Status: Open
+Status: Feedback
Type: Bug
Package:*General Issues
Operating System: linux
PHP Version:5.4.0
Block user comment: N
Private report: N
New Comment:
Thank you for this bug report. To properly diagnose the problem, we
need a short but complete example script to be able to reproduce
this bug ourselves.
A proper reproducing script starts with ,
is max. 10-20 lines long and does not require any external
resources such as databases, etc. If the script requires a
database to demonstrate the issue, please make sure it creates
all necessary tables, stored procedures etc.
Please avoid embedding huge scripts into the report.
Previous Comments:
[2012-03-08 16:14:40] anil at saog dot net
Description:
There happens a "segmentation fault" while traversing big arrays with "foreach".
A sample backtrace:
/opt/uwsgi/uwsgi(uwsgi_backtrace+0x2a) [0x807981a]
/opt/uwsgi/uwsgi(uwsgi_segfault+0x2c) [0x807990c]
/lib/libc.so.6 [0xb7b02e28]
/opt/php54/lib/libphp5.so(zend_object_std_dtor+0x88) [0xb6509948]
/opt/php54/lib/libphp5.so(zend_objects_free_object_storage+0x12) [0xb6509982]
/opt/php54/lib/libphp5.so(zend_objects_store_free_object_storage+0x78)
[0xb650ed28]
/opt/php54/lib/libphp5.so [0xb64e021c]
/opt/php54/lib/libphp5.so [0xb64eb623]
/opt/php54/lib/libphp5.so(php_request_shutdown+0x172) [0xb648fe52]
./php_plugin.so(uwsgi_php_request+0x1e0) [0xb7fb8e90]
Seg-faulted code (probably with 100.000 items or more):
foreach ($options as $item) {
if ($item['value'] == $value) {
return $item['label'];
}
}
Expected result:
no segmentation fault
Actual result:
--
segmentation fault
--
Edit this bug report at https://bugs.php.net/bug.php?id=61328&edit=1
[PHP-BUG] Bug #61328 [NEW]: segmentation fault while traversing big arrays with foreach
From:
Operating system: linux
PHP version: 5.4.0
Package: *General Issues
Bug Type: Bug
Bug description:segmentation fault while traversing big arrays with foreach
Description:
There happens a "segmentation fault" while traversing big arrays with
"foreach".
A sample backtrace:
/opt/uwsgi/uwsgi(uwsgi_backtrace+0x2a) [0x807981a]
/opt/uwsgi/uwsgi(uwsgi_segfault+0x2c) [0x807990c]
/lib/libc.so.6 [0xb7b02e28]
/opt/php54/lib/libphp5.so(zend_object_std_dtor+0x88) [0xb6509948]
/opt/php54/lib/libphp5.so(zend_objects_free_object_storage+0x12)
[0xb6509982]
/opt/php54/lib/libphp5.so(zend_objects_store_free_object_storage+0x78)
[0xb650ed28]
/opt/php54/lib/libphp5.so [0xb64e021c]
/opt/php54/lib/libphp5.so [0xb64eb623]
/opt/php54/lib/libphp5.so(php_request_shutdown+0x172) [0xb648fe52]
./php_plugin.so(uwsgi_php_request+0x1e0) [0xb7fb8e90]
Seg-faulted code (probably with 100.000 items or more):
foreach ($options as $item) {
if ($item['value'] == $value) {
return $item['label'];
}
}
Expected result:
no segmentation fault
Actual result:
--
segmentation fault
--
Edit bug report at https://bugs.php.net/bug.php?id=61328&edit=1
--
Try a snapshot (PHP 5.4):
https://bugs.php.net/fix.php?id=61328&r=trysnapshot54
Try a snapshot (PHP 5.3):
https://bugs.php.net/fix.php?id=61328&r=trysnapshot53
Try a snapshot (trunk):
https://bugs.php.net/fix.php?id=61328&r=trysnapshottrunk
Fixed in SVN:
https://bugs.php.net/fix.php?id=61328&r=fixed
Fixed in SVN and need be documented:
https://bugs.php.net/fix.php?id=61328&r=needdocs
Fixed in release:
https://bugs.php.net/fix.php?id=61328&r=alreadyfixed
Need backtrace:
https://bugs.php.net/fix.php?id=61328&r=needtrace
Need Reproduce Script:
https://bugs.php.net/fix.php?id=61328&r=needscript
Try newer version:
https://bugs.php.net/fix.php?id=61328&r=oldversion
Not developer issue:
https://bugs.php.net/fix.php?id=61328&r=support
Expected behavior:
https://bugs.php.net/fix.php?id=61328&r=notwrong
Not enough info:
https://bugs.php.net/fix.php?id=61328&r=notenoughinfo
Submitted twice:
https://bugs.php.net/fix.php?id=61328&r=submittedtwice
register_globals:
https://bugs.php.net/fix.php?id=61328&r=globals
PHP 4 support discontinued:
https://bugs.php.net/fix.php?id=61328&r=php4
Daylight Savings:https://bugs.php.net/fix.php?id=61328&r=dst
IIS Stability:
https://bugs.php.net/fix.php?id=61328&r=isapi
Install GNU Sed:
https://bugs.php.net/fix.php?id=61328&r=gnused
Floating point limitations:
https://bugs.php.net/fix.php?id=61328&r=float
No Zend Extensions:
https://bugs.php.net/fix.php?id=61328&r=nozend
MySQL Configuration Error:
https://bugs.php.net/fix.php?id=61328&r=mysqlcfg
[PHP-BUG] Bug #61327 [NEW]: PDO complain about Invalid parameter number
From:
Operating system: linux
PHP version: 5.3.10
Package: PDO related
Bug Type: Bug
Bug description:PDO complain about Invalid parameter number
Description:
The query
INSERT INTO $table VALUES (\"first value\");
-- dam'd quote
INSERT INTO $table VALUES (\"foo : ba'r \"),
(\"foo.:bar\");
Throws
Warning: PDOStatement::execute(): SQLSTATE[HY093]: Invalid parameter
number: no parameters were bound
But doesn't
- without first query before comment
- without comment
- with escaped quote
- with space after last colon
Test script:
---
// This query doesn't work
$q1 = "INSERT INTO $table VALUES (\"first value\");
-- dam'd quote
INSERT INTO $table VALUES (\"foo : ba'r \"),
(\"foo.:bar\"); ";
// But all these doesn't have any pb
$q2 = "-- dam'd quote
INSERT INTO $table VALUES (\"foo : ba'r \"),
(\"foo.:bar\"); "; // without first one (before comment)
$q3 = "INSERT INTO $table VALUES (\"first value\");
INSERT INTO $table VALUES (\"foo : ba'r \"),
(\"foo.:bar\"); "; // without comment
$q4 = "INSERT INTO $table VALUES (\"first value\");
-- dam'd quote
INSERT INTO $table VALUES (\"foo : ba\'r \"),
(\"foo.:bar\"); "; // with escaped quote
$q5 = "INSERT INTO $table VALUES (\"first value\");
-- dam'd quote
INSERT INTO $table VALUES (\"foo : ba'r \"),
(\"foo.: bar\"); "; // with space after last colon
try {
$pdo = new PDO($dsn, $user, $pass, $options);
$stmt = $pdo->prepare($query);
$stmt->execute();
}
catch (Exception $e) {
echo "Failed : " .$e->getMessage();
}
Expected result:
No warning
Actual result:
--
Warning: PDOStatement::execute(): SQLSTATE[HY093]: Invalid parameter
number: no parameters were bound
--
Edit bug report at https://bugs.php.net/bug.php?id=61327&edit=1
--
Try a snapshot (PHP 5.4):
https://bugs.php.net/fix.php?id=61327&r=trysnapshot54
Try a snapshot (PHP 5.3):
https://bugs.php.net/fix.php?id=61327&r=trysnapshot53
Try a snapshot (trunk):
https://bugs.php.net/fix.php?id=61327&r=trysnapshottrunk
Fixed in SVN:
https://bugs.php.net/fix.php?id=61327&r=fixed
Fixed in SVN and need be documented:
https://bugs.php.net/fix.php?id=61327&r=needdocs
Fixed in release:
https://bugs.php.net/fix.php?id=61327&r=alreadyfixed
Need backtrace:
https://bugs.php.net/fix.php?id=61327&r=needtrace
Need Reproduce Script:
https://bugs.php.net/fix.php?id=61327&r=needscript
Try newer version:
https://bugs.php.net/fix.php?id=61327&r=oldversion
Not developer issue:
https://bugs.php.net/fix.php?id=61327&r=support
Expected behavior:
https://bugs.php.net/fix.php?id=61327&r=notwrong
Not enough info:
https://bugs.php.net/fix.php?id=61327&r=notenoughinfo
Submitted twice:
https://bugs.php.net/fix.php?id=61327&r=submittedtwice
register_globals:
https://bugs.php.net/fix.php?id=61327&r=globals
PHP 4 support discontinued:
https://bugs.php.net/fix.php?id=61327&r=php4
Daylight Savings:https://bugs.php.net/fix.php?id=61327&r=dst
IIS Stability:
https://bugs.php.net/fix.php?id=61327&r=isapi
Install GNU Sed:
https://bugs.php.net/fix.php?id=61327&r=gnused
Floating point limitations:
https://bugs.php.net/fix.php?id=61327&r=float
No Zend Extensions:
https://bugs.php.net/fix.php?id=61327&r=nozend
MySQL Configuration Error:
https://bugs.php.net/fix.php?id=61327&r=mysqlcfg
Req #61265 [Opn]: __autoload should know about traits
Edit report at https://bugs.php.net/bug.php?id=61265&edit=1 ID: 61265 User updated by:manchokapitancho at gmail dot com Reported by:manchokapitancho at gmail dot com Summary:__autoload should know about traits Status: Open Type: Feature/Change Request Package:Class/Object related PHP Version:5.4.0 Block user comment: N Private report: N New Comment: Yes, there is a use case. Currently, I use a workaround but in general, the idea behind is that after I locate the file, corresponding to the class name being autoloaded, I require_once the file and then check if the class is really inside (class_exists). As of 5.4, class_exists returns false for traits and I have to use class_exists || trait_exists. Not a big deal, really, but it is still possible to have different paths for classes (ex. /classes) and different one for traits (/traits). Previous Comments: [2012-03-08 13:26:06] shiranai7 at hotmail dot com Sorry.. it should say "It is NOT a critical feature" instead of "NOW". [2012-03-08 13:25:04] shiranai7 at hotmail dot com It is now a critical feature but it would be nice. For example - if I decided to format the filenames depending on what is being autoloaded (class/interface/trait) I could not easily do it. Adding a second argument to the autoload callback would make this possible and should not break anything. [2012-03-04 17:11:11] g...@php.net Could you elaborate a bit on the usecase? Until now, there didn't seem to be the need to handle interfaces differently in an autoloader. Why would you treat traits differently from classes and interfaces? [2012-03-03 13:10:25] manchokapitancho at gmail dot com Description: Currently, __autoload is automatically called when a class is not found. As of 5.4.0, it is also called when a trait is not found. It is also called when an interface is not found. Unfortunately, there is no way to understand what type of resource is being autoloaded. So I suggest that a second optional argument is added to __autoload. It can receive three possible values from the PHP engine - for example: AUTOLOAD_CLASS, AUTOLOAD_TRAIT and AUTOLOAD_INSTANCE. This way, a better autoload handling can be achieved. -- Edit this bug report at https://bugs.php.net/bug.php?id=61265&edit=1
Bug #61321 [ReO->Csd]: Crash on __call + __invoke magic
Edit report at https://bugs.php.net/bug.php?id=61321&edit=1
ID: 61321
Updated by: larue...@php.net
Reported by:lol at nrzw dot net
Summary:Crash on __call + __invoke magic
-Status: Re-Opened
+Status: Closed
Type: Bug
Package:Reproducible crash
Operating System: Linux (CentOS, Deb)
PHP Version:5.3.10
-Assigned To:
+Assigned To:laruence
Block user comment: N
Private report: N
Previous Comments:
[2012-03-08 13:30:18] larue...@php.net
@cataphract it's a knew segfault, that is the call stack exceeded. so I think
it's
okey to close it.
[2012-03-08 08:23:38] cataphr...@php.net
If it segfaults, there's still a bug. Please don't close it.
[2012-03-08 02:58:30] lol at nrzw dot net
@larue...@php.net
I suppose I did =) I don't see how I missed that (I chopped down my code as I
am obviously not working with bags).
I don't see why this would cause a segfault instead of issuing a
failure/warning notice, but that works =) Thank you!
[2012-03-08 02:53:54] larue...@php.net
do you mean like this:
bagone = new bag();
}
public function __call($method, array $args = array()) {
$this->bagone->__invoke($args);
}
}
$c = new bag_container();
$c->bagone('e', array('wtf'));
[2012-03-07 22:07:51] lol at nrzw dot net
Description:
Using PHP versions 5.3.3 up to 5.3.10:
A 'container' has many 'bags', but few methods. Each 'bag' has its own methods
that are callable through it's magic __invoke method. No methods collide with
the properties of the 'container', so one would expect that:
bag_container->bagone('e', array('Some Text'))
Would trigger bag_container's __call (since no method 'bagone' exists in
'bag_container'), which would further trigger the __invoke method in class
'bag'.
Unfortunately, it just creates a segfault =|
I see that there is a related bug
(https://bugs.php.net/bug.php?id=53195&edit=2), but since the bug has not been
updated and this one produces different behavior (segfault), I felt that I
should resubmit. Apologies if that's wrong.
Test script:
---
class bag {
public function e($something) {
echo $something;
}
public function __invoke() {
return call_user_func_array(array($this, $method), $args);
}
}
class bag_container {
public $bagone;
public function __construct() {
$this->bagone = new bag();
}
public function __call($method, array $args = array()) {
return call_user_func_array(array($this, $method), $args);
}
}
$c = new bag_container();
$c->bagone('e', array('wtf'));
Expected result:
One would expect 'wtf' to be echo'd.
Actual result:
--
Segmentation fault.
--
Edit this bug report at https://bugs.php.net/bug.php?id=61321&edit=1
Bug #61321 [ReO]: Crash on __call + __invoke magic
Edit report at https://bugs.php.net/bug.php?id=61321&edit=1
ID: 61321
Updated by: larue...@php.net
Reported by:lol at nrzw dot net
Summary:Crash on __call + __invoke magic
Status: Re-Opened
Type: Bug
Package:Reproducible crash
Operating System: Linux (CentOS, Deb)
PHP Version:5.3.10
Block user comment: N
Private report: N
New Comment:
@cataphract it's a knew segfault, that is the call stack exceeded. so I think
it's
okey to close it.
Previous Comments:
[2012-03-08 08:23:38] cataphr...@php.net
If it segfaults, there's still a bug. Please don't close it.
[2012-03-08 02:58:30] lol at nrzw dot net
@larue...@php.net
I suppose I did =) I don't see how I missed that (I chopped down my code as I
am obviously not working with bags).
I don't see why this would cause a segfault instead of issuing a
failure/warning notice, but that works =) Thank you!
[2012-03-08 02:53:54] larue...@php.net
do you mean like this:
bagone = new bag();
}
public function __call($method, array $args = array()) {
$this->bagone->__invoke($args);
}
}
$c = new bag_container();
$c->bagone('e', array('wtf'));
[2012-03-07 22:07:51] lol at nrzw dot net
Description:
Using PHP versions 5.3.3 up to 5.3.10:
A 'container' has many 'bags', but few methods. Each 'bag' has its own methods
that are callable through it's magic __invoke method. No methods collide with
the properties of the 'container', so one would expect that:
bag_container->bagone('e', array('Some Text'))
Would trigger bag_container's __call (since no method 'bagone' exists in
'bag_container'), which would further trigger the __invoke method in class
'bag'.
Unfortunately, it just creates a segfault =|
I see that there is a related bug
(https://bugs.php.net/bug.php?id=53195&edit=2), but since the bug has not been
updated and this one produces different behavior (segfault), I felt that I
should resubmit. Apologies if that's wrong.
Test script:
---
class bag {
public function e($something) {
echo $something;
}
public function __invoke() {
return call_user_func_array(array($this, $method), $args);
}
}
class bag_container {
public $bagone;
public function __construct() {
$this->bagone = new bag();
}
public function __call($method, array $args = array()) {
return call_user_func_array(array($this, $method), $args);
}
}
$c = new bag_container();
$c->bagone('e', array('wtf'));
Expected result:
One would expect 'wtf' to be echo'd.
Actual result:
--
Segmentation fault.
--
Edit this bug report at https://bugs.php.net/bug.php?id=61321&edit=1
Req #61265 [Com]: __autoload should know about traits
Edit report at https://bugs.php.net/bug.php?id=61265&edit=1 ID: 61265 Comment by: shiranai7 at hotmail dot com Reported by:manchokapitancho at gmail dot com Summary:__autoload should know about traits Status: Open Type: Feature/Change Request Package:Class/Object related PHP Version:5.4.0 Block user comment: N Private report: N New Comment: Sorry.. it should say "It is NOT a critical feature" instead of "NOW". Previous Comments: [2012-03-08 13:25:04] shiranai7 at hotmail dot com It is now a critical feature but it would be nice. For example - if I decided to format the filenames depending on what is being autoloaded (class/interface/trait) I could not easily do it. Adding a second argument to the autoload callback would make this possible and should not break anything. [2012-03-04 17:11:11] g...@php.net Could you elaborate a bit on the usecase? Until now, there didn't seem to be the need to handle interfaces differently in an autoloader. Why would you treat traits differently from classes and interfaces? [2012-03-03 13:10:25] manchokapitancho at gmail dot com Description: Currently, __autoload is automatically called when a class is not found. As of 5.4.0, it is also called when a trait is not found. It is also called when an interface is not found. Unfortunately, there is no way to understand what type of resource is being autoloaded. So I suggest that a second optional argument is added to __autoload. It can receive three possible values from the PHP engine - for example: AUTOLOAD_CLASS, AUTOLOAD_TRAIT and AUTOLOAD_INSTANCE. This way, a better autoload handling can be achieved. -- Edit this bug report at https://bugs.php.net/bug.php?id=61265&edit=1
Req #61265 [Com]: __autoload should know about traits
Edit report at https://bugs.php.net/bug.php?id=61265&edit=1 ID: 61265 Comment by: shiranai7 at hotmail dot com Reported by:manchokapitancho at gmail dot com Summary:__autoload should know about traits Status: Open Type: Feature/Change Request Package:Class/Object related PHP Version:5.4.0 Block user comment: N Private report: N New Comment: It is now a critical feature but it would be nice. For example - if I decided to format the filenames depending on what is being autoloaded (class/interface/trait) I could not easily do it. Adding a second argument to the autoload callback would make this possible and should not break anything. Previous Comments: [2012-03-04 17:11:11] g...@php.net Could you elaborate a bit on the usecase? Until now, there didn't seem to be the need to handle interfaces differently in an autoloader. Why would you treat traits differently from classes and interfaces? [2012-03-03 13:10:25] manchokapitancho at gmail dot com Description: Currently, __autoload is automatically called when a class is not found. As of 5.4.0, it is also called when a trait is not found. It is also called when an interface is not found. Unfortunately, there is no way to understand what type of resource is being autoloaded. So I suggest that a second optional argument is added to __autoload. It can receive three possible values from the PHP engine - for example: AUTOLOAD_CLASS, AUTOLOAD_TRAIT and AUTOLOAD_INSTANCE. This way, a better autoload handling can be achieved. -- Edit this bug report at https://bugs.php.net/bug.php?id=61265&edit=1
Bug #61043 [Ctl->Fbk]: Regression in magic_quotes_gpc fix (CVE-2012-0831)
Edit report at https://bugs.php.net/bug.php?id=61043&edit=1
ID: 61043
Updated by: johan...@php.net
Reported by:ond...@php.net
Summary:Regression in magic_quotes_gpc fix (CVE-2012-0831)
-Status: Critical
+Status: Feedback
Type: Bug
Package:Variables related
PHP Version:5.3SVN-2012-02-10 (SVN)
Assigned To:johannes
Block user comment: N
Private report: N
New Comment:
I think this was fixed in r323016. Please verify.
Previous Comments:
[2012-03-05 22:46:30] paj...@php.net
Johannes, can you check this please?
[2012-02-13 18:37:04] sbeat...@php.net
OndÅej's patch is the patch we went with in Ubuntu. I verified in our testing
that it did address the issue.
[2012-02-10 13:19:41] ond...@php.net
I can confirm that the attached patch fixes the reported problem:
root@howl:/tmp# /tmp/buildd/php5-5.3.3/cgi-build/sapi/cli/php -c /tmp/php.ini -
r 'var_dump(ini_get("magic_quotes_gpc"));'
string(1) "1"
root@howl:/tmp# grep ^magic_quotes_gpc /tmp/php.ini
magic_quotes_gpc = On
root@howl:/tmp# /tmp/buildd/php5-5.3.3/cgi-build/sapi/cli/php -c /tmp/php.ini -
r 'var_dump(ini_get("magic_quotes_gpc"));'
string(1) "1"
root@howl:/tmp# emacs php.ini
root@howl:/tmp# grep ^magic_quotes_gpc /tmp/php.ini
magic_quotes_gpc = Off
root@howl:/tmp# /tmp/buildd/php5-5.3.3/cgi-build/sapi/cli/php -c /tmp/php.ini -
r 'var_dump(ini_get("magic_quotes_gpc"));'
string(0) ""
[2012-02-10 12:44:17] ond...@php.net
The following patch has been added/updated:
Patch Name: magic_quotes_gpc-regression
Revision: 1328877857
URL:
https://bugs.php.net/patch-display.php?bug=61043&patch=magic_quotes_gpc-regression&revision=1328877857
[2012-02-10 12:43:45] ond...@php.net
Description:
Description available here:
https://bugs.launchpad.net/ubuntu/+source/php5/+bug/930115
Basically the attached patch does replace the second location of
PG(magic_quotes_gpc) with the zend_alter_ini_entry_ex:
- PG(magic_quotes_gpc) = magic_quotes_gpc;
+
+ if (magic_quotes_gpc) {
+ zend_alter_ini_entry_ex("magic_quotes_gpc",
sizeof("magic_quotes_gpc"), "1", 1, ZEND_INI_SYSTEM, ZEND_INI_STAGE_ACTIVATE, 1
TSRMLS_CC);
+ }
I could be wrong, since my knowledge of PHP internals is lim(knowledge) = 0,
but
this seems to follow the logic of first change.
--
Edit this bug report at https://bugs.php.net/bug.php?id=61043&edit=1
Bug #55334 [Fbk->Asn]: MySQLi make mod_php crash on stress test
Edit report at https://bugs.php.net/bug.php?id=55334&edit=1 ID: 55334 Updated by: johan...@php.net Reported by:bruno at chalopin dot fr Summary:MySQLi make mod_php crash on stress test -Status: Feedback +Status: Assigned Type: Bug Package:MySQLi related Operating System: Windows 2008r2 x64 PHP Version:5.3.7RC4 -Assigned To: +Assigned To:mattficken Block user comment: N Private report: N New Comment: 13:58 <@johannes> Pierre: can you check 5.3 in your stress tests regarding 55334? On Linux and Solaris I can't hit it in threaded context anymore. 5.4/trunk seems to be fixed by dmitry's property refactoring work (svn r299692) 14:05 <@Pierre> johannes, add a comment to the bug and assign it to matt. Previous Comments: [2012-03-08 12:55:25] johan...@php.net Seems like this was a bug from very old times in mysqli. I've applied a fix to PHP_5_3 and couldn't trigger an issue anymore with lots of concurrency over a longer period. A fix for 5.4 and trunk is not needed as the code had been refactored before. Please run your tests, too. [2012-03-08 12:52:03] johan...@php.net Automatic comment from SVN on behalf of johannes Revision: http://svn.php.net/viewvc/?view=revision&revision=324022 Log: Use correct property ctor, should fix threading issue in bug #55334 # The code was refactored in 5_4/trunk, no need to merge [2012-01-19 07:40:46] ninzya at inbox dot lv Got apache crashing due to MySQLi as well. Here's the bug report: https://bugs.php.net/bug.php?id=55334 [2011-10-21 14:47:09] doug at sevone dot com I have been able to reproduce a similar (if not the same) crash by this SIMPLER script: On another machine, I have about 12 threads doing GET requests to that page simultaneously. I usually see a crash after about 1-2 seconds. As far as I can tell, this is a "mysqli" issue only (involving thread-safety). If I disable mysqlnd, then I still see the same problem. I see this on MySQL 5.5 and 5.1. However, the MySQL version should NOT matter, since I can reproduce the problem without EVER connecting to a MySQL box, and since it crashes using mysqlnd. OS: gentoo (x86_64) Apache: www-servers/apache-2.2.14-r1 Apache: www-servers/apache-2.2.21 PHP: dev-lang/php-5.3.6 PHP: dev-lang/php-5.3.8 [2011-08-02 07:40:05] bruno at chalopin dot fr More informations : The test database : --- CREATE TABLE `test` ( `id` int(11) NOT NULL, `data` text COLLATE latin1_general_ci, PRIMARY KEY (`id`) ) ENGINE=MyISAM DEFAULT CHARSET=latin1 COLLATE=latin1_general_ci; INSERT INTO `test`(`id`,`data`) VALUES (1,'foo'),(2,'bar'),(3,'gru'); Software version : -- MySql 5.5.14 x86 Apache 2.2.19 x86 VC9 (from apachelounge) Both have default conf file. 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 https://bugs.php.net/bug.php?id=55334 -- Edit this bug report at https://bugs.php.net/bug.php?id=55334&edit=1
Bug #55334 [Opn->Fbk]: MySQLi make mod_php crash on stress test
Edit report at https://bugs.php.net/bug.php?id=55334&edit=1 ID: 55334 Updated by: johan...@php.net Reported by:bruno at chalopin dot fr Summary:MySQLi make mod_php crash on stress test -Status: Open +Status: Feedback Type: Bug Package:MySQLi related Operating System: Windows 2008r2 x64 PHP Version:5.3.7RC4 Block user comment: N Private report: N New Comment: Seems like this was a bug from very old times in mysqli. I've applied a fix to PHP_5_3 and couldn't trigger an issue anymore with lots of concurrency over a longer period. A fix for 5.4 and trunk is not needed as the code had been refactored before. Please run your tests, too. Previous Comments: [2012-03-08 12:52:03] johan...@php.net Automatic comment from SVN on behalf of johannes Revision: http://svn.php.net/viewvc/?view=revision&revision=324022 Log: Use correct property ctor, should fix threading issue in bug #55334 # The code was refactored in 5_4/trunk, no need to merge [2012-01-19 07:40:46] ninzya at inbox dot lv Got apache crashing due to MySQLi as well. Here's the bug report: https://bugs.php.net/bug.php?id=55334 [2011-10-21 14:47:09] doug at sevone dot com I have been able to reproduce a similar (if not the same) crash by this SIMPLER script: On another machine, I have about 12 threads doing GET requests to that page simultaneously. I usually see a crash after about 1-2 seconds. As far as I can tell, this is a "mysqli" issue only (involving thread-safety). If I disable mysqlnd, then I still see the same problem. I see this on MySQL 5.5 and 5.1. However, the MySQL version should NOT matter, since I can reproduce the problem without EVER connecting to a MySQL box, and since it crashes using mysqlnd. OS: gentoo (x86_64) Apache: www-servers/apache-2.2.14-r1 Apache: www-servers/apache-2.2.21 PHP: dev-lang/php-5.3.6 PHP: dev-lang/php-5.3.8 [2011-08-02 07:40:05] bruno at chalopin dot fr More informations : The test database : --- CREATE TABLE `test` ( `id` int(11) NOT NULL, `data` text COLLATE latin1_general_ci, PRIMARY KEY (`id`) ) ENGINE=MyISAM DEFAULT CHARSET=latin1 COLLATE=latin1_general_ci; INSERT INTO `test`(`id`,`data`) VALUES (1,'foo'),(2,'bar'),(3,'gru'); Software version : -- MySql 5.5.14 x86 Apache 2.2.19 x86 VC9 (from apachelounge) Both have default conf file. [2011-08-01 09:16:40] bruno at chalopin dot fr Description: mod_php crashes on stress test (ab -n 1 -c 20) due to MySqli (the use of the mysql extension don't make it crash) Test script: --- Test MySqli ' . $row['id'] . ' - ' . $row['data'] . ''; } ?> Actual result: -- Type of Analysis Performed Crash Analysis Machine Name CHALOPIN-2008R2 Operating System Unexpected Service Pack 1 Number Of Processors 8 Process ID 3444 Process Image D:\SysperTec\webstack\Apache2\bin\httpd.exe System Up-Time 01:19:31 Process Up-Time 00:00:01 Thread 16 - System ID 3560 Entry point msvcr90!_endthreadex+6f Create time 01/08/2011 10:35:10 Time spent in user mode 0 Days 0:0:0.0 Time spent in kernel mode 0 Days 0:0:0.0 Function Arg 1 Arg 2 Arg 3 Source php5ts!zend_register_internal_class_ex+b77 04ae90a0 6f21e664 016b02f0 php5ts!_efree+2e 016b02f0 0544ed20 6f223957 php5ts!_zval_ptr_dtor+54 0544f01c 0544ef50 0544f2b8 php5ts!zend_hash_destroy+27 0544dbe0 04a94b58 72451201 php5ts!zend_object_std_dtor+2b 0544f2b8 04a94b58 05442e4c php_mysqli!php_clear_mysql+d1 0544f2b8 04a94b58 04a94b58 php5ts!zend_objects_store_del_ref_by_handle_ex+1c1 0001 72465600 04a94b58 php5ts!zend_objects_store_del_ref+1a 0544e8b0 04a94b58 php5ts!_zval_dtor_func+7f 0544e8b0 0544dce0 6f223ad2 php5ts!_zval_ptr_dtor+4b 0544dcec 6f223d83 04a94b58 php5ts!zend_hash_clean+112 04a94b58 0262fa9c 0262fa8c php5ts!zend_hash_reverse_apply+53 04ae7218 6f21deb0 04a94b58 php5ts!shutdown_destructors+77 04a94b58 04a94b58 0262fae0 php5ts!zend_call_destructors+42 04a94b58 04a94b58 php5ts!php_request_shutdown+f0 0004 0156df20 php5apache2_2!zm_info_apache+1801 01d55f30 01d55f30 00cfb3e8 libhttpd!ap_run_handler+25 PHP5TS!ZEND_REGISTER_INTERNAL_CLASS_EX+B77In httpd__PID__3444__Da
[PHP-BUG] Bug #61325 [NEW]: FastCGI keeps dieing
From: Operating system: CentOS PHP version: 5.4.0 Package: CGI/CLI related Bug Type: Bug Bug description:FastCGI keeps dieing Description: Currently running Lighttpd which returns a 500 - Internal Server Error with this log: 2012-03-08 12:26:32: (mod_fastcgi.c.2568) unexpected end-of-file (perhaps the fastcgi process died): pid: 10734 socket: unix:/tmp/php.socket10726-3 2012-03-08 12:26:32: (mod_fastcgi.c.3356) response not received, request sent: 879 on socket: unix:/tmp/php.socket10726-3 for /index.php?, closing connection php -v: PHP 5.4.0 (cli) (built: Mar 7 2012 20:14:12) Copyright (c) 1997-2012 The PHP Group Zend Engine v2.4.0, Copyright (c) 1998-2012 Zend Technologies php-cgi -v: PHP Warning: Unknown: function '1' not found or invalid function name in Unknown on line 0 PHP 5.4.0 (cgi-fcgi) (built: Mar 7 2012 20:14:29) Copyright (c) 1997-2012 The PHP Group Zend Engine v2.4.0, Copyright (c) 1998-2012 Zend Technologies configure line: ./configure --with-config-file-path=/etc --with-config-file-scan-dir=/etc/php.d - -with-libdir=lib64 --with-mysql --with-mysqli --with-zlib --with-curl --with- mcrypt --enable-cgi If there is anything else I can do to help I will. Sorry, this is my first bug report. -- Edit bug report at https://bugs.php.net/bug.php?id=61325&edit=1 -- Try a snapshot (PHP 5.4): https://bugs.php.net/fix.php?id=61325&r=trysnapshot54 Try a snapshot (PHP 5.3): https://bugs.php.net/fix.php?id=61325&r=trysnapshot53 Try a snapshot (trunk): https://bugs.php.net/fix.php?id=61325&r=trysnapshottrunk Fixed in SVN: https://bugs.php.net/fix.php?id=61325&r=fixed Fixed in SVN and need be documented: https://bugs.php.net/fix.php?id=61325&r=needdocs Fixed in release: https://bugs.php.net/fix.php?id=61325&r=alreadyfixed Need backtrace: https://bugs.php.net/fix.php?id=61325&r=needtrace Need Reproduce Script: https://bugs.php.net/fix.php?id=61325&r=needscript Try newer version: https://bugs.php.net/fix.php?id=61325&r=oldversion Not developer issue: https://bugs.php.net/fix.php?id=61325&r=support Expected behavior: https://bugs.php.net/fix.php?id=61325&r=notwrong Not enough info: https://bugs.php.net/fix.php?id=61325&r=notenoughinfo Submitted twice: https://bugs.php.net/fix.php?id=61325&r=submittedtwice register_globals: https://bugs.php.net/fix.php?id=61325&r=globals PHP 4 support discontinued: https://bugs.php.net/fix.php?id=61325&r=php4 Daylight Savings:https://bugs.php.net/fix.php?id=61325&r=dst IIS Stability: https://bugs.php.net/fix.php?id=61325&r=isapi Install GNU Sed: https://bugs.php.net/fix.php?id=61325&r=gnused Floating point limitations: https://bugs.php.net/fix.php?id=61325&r=float No Zend Extensions: https://bugs.php.net/fix.php?id=61325&r=nozend MySQL Configuration Error: https://bugs.php.net/fix.php?id=61325&r=mysqlcfg
Bug #61253 [Asn]: Wrappers opened with errors concurrency problem
Edit report at https://bugs.php.net/bug.php?id=61253&edit=1
ID: 61253
Updated by: cataphr...@php.net
Reported by:cataphr...@php.net
Summary:Wrappers opened with errors concurrency problem
Status: Assigned
Type: Bug
Package:Streams related
Operating System: Any (ZTS)
PHP Version:5.4SVN-2012-03-02 (SVN)
Assigned To:mattficken
Block user comment: N
Private report: N
New Comment:
I've committed the patch. Testing would still be useful.
Previous Comments:
[2012-03-08 12:30:50] cataphr...@php.net
Automatic comment from SVN on behalf of cataphract
Revision: http://svn.php.net/viewvc/?view=revision&revision=324020
Log: - Fixed bug #61253: Wrappers opened with errors concurrency problem
#NOTE: There is a very small possibility that this will further break
#extensions that access wrapper->{err_stack, err_count}. On PECL SVN, rar is
the
#only one and it may leak memory after this. I say "further break"
because
#extensions that do that are already broken (will segfault) under ZTS, which is
#why this patch is necessary.
#There was what I deem as tacit acceptance from 5.3/5.4 RMs on this.
[2012-03-07 14:05:35] cataphr...@php.net
The following patch has been added/updated:
Patch Name: bug61253.diff
Revision: 1331129135
URL:
https://bugs.php.net/patch-display.php?bug=61253&patch=bug61253.diff&revision=1331129135
[2012-03-03 20:42:12] paj...@php.net
Matt, can you test this patch please? and add the test to our suites while
being
at it :)
[2012-03-02 22:13:36] cataphr...@php.net
Pierre, please see if this fixes the problem.
[2012-03-02 22:13:02] cataphr...@php.net
The following patch has been added/updated:
Patch Name: bug61253.diff
Revision: 1330726381
URL:
https://bugs.php.net/patch-display.php?bug=61253&patch=bug61253.diff&revision=1330726381
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
https://bugs.php.net/bug.php?id=61253
--
Edit this bug report at https://bugs.php.net/bug.php?id=61253&edit=1
Bug #49764 [Asn->Wfx]: number_format() fails (randomly?)
Edit report at https://bugs.php.net/bug.php?id=49764&edit=1 ID: 49764 Updated by: paj...@php.net Reported by:tec at baufi24 dot de Summary:number_format() fails (randomly?) -Status: Assigned +Status: Wont fix Type: Bug Package:Math related Operating System: Windows PHP Version:* Assigned To:pajoye Block user comment: N Private report: N New Comment: VC9 builds do not have this problem anymore and we do not support VC6 anymore. Previous Comments: [2010-11-18 07:19:00] tec at baufi24 dot de The solution for this bug is to use the right PHP version for Windows Server. If you use IIS then you have to install a VC9 Version. http://windows.php.net/download/ [2010-11-18 00:07:16] adenman at tmea dot org A follow-up: I just created a new site on the server for other testing and the test site does not exhibit this behavior. The test site is completely separate from the main site, but I've copied the settings exactly from the main site and am using the same PHP executable and an exact copy of the php.ini file. I've run diffs on several configuration files and cannot find any differences other than name and site paths. With both sites running on the server, I ran the test several times on each. The main site always gives me '16.:' (wrong) and the test site always gives me '17' (correct). I have no idea what this means, but figured it might be helpful to someone looking into this. [2010-09-01 19:40:46] adenman at tmea dot org I am able to reproduce this. PHP: 5.2.13 OS: Windows 2008 Standard Server, 64-bit (Windows NT WEB2 6.1 build 7600 from phpinfo) CPU: AMD Opteron 6172 Using the test posted by 'adrianv at taly dot net' on bug http://bugs.php.net/bug.php?id=47418 and changing to list whole numbers, I have found the following numbers exhibit this odd behavior: 17, 19, 29, 39 and multiples of ten of these numbers (170, 1700, 17000, etc) They get output as: 16.:0, 18.:0, 28.:0, 38.:0, etc when using the number_format or sprintf functions to format them with decimal places. In addition to number_format and sprintf, I have found that once you do basic math with these numbers and float numbers, even just echoing the result will trigger this bug. The bcmath functions do not exhibit this behavior. Example: $tot = 17; $math = $tot * 1.5; $math = $math / 1.5; $math2 = bcmul($tot, 1.5, 1); $math2 = bcdiv($math2, 1.5, 1); echo $math //outputs 16.:, expect 17 echo $math2 //outputs 17.0, expect 17.0 [2010-08-04 13:15:33] codeslinger at compsalot dot com it's not random, it's just very hard to reproduce. only certain specific values will trigger this bug. and the weird thing is that the specific value changes from build to build and with different oses. this bug is a dup of the many other existing reports about this bug. bugs 43487, 47304, 47716, 47732, 51396 etc.. this bug has been encountered in: php 5.2.11, 5.2.12, 5.2.13, 5.2.25, 5.2.26, 5.2.9... it has been found on Windows 2000, Windows XP, Windows 2003, ubuntu, mandriva. This bug has been reproduced both with and without xdebug and/or zend debugger. You want to reproduce this bug???!!! it's very easy, I will give you a one-liner install ubuntu 8.0.4 install the standard php that comes with ubuntu 8.0.4 now run this: echo (string) (double) -0.0; actual result: -0.0: Note that changing the float percision greatly affects the bug. The thing is that the value is very specific to the actual build and the actual os. For instance it was reported that on Windows nt 5.2 (2003?) the following will fail: echo round(1451,2); actual result: 1450.:0 It has also been reported that using BCMath helps but does not totally solve this problem "3 out of 4 were fixed". But despite all of the above, this bug keeps getting blown off as not repro!!! :-( Consider the following true story: once upon a time, there was a German insurance company sued by a client whoâd lost a lot of money through the insurance companyâs flawed bookkeeping. The insurance company went into a panic and started hunting the bug and were able to prove it was caused by customized software theyâd bought from a German software house. They sued the software house. The software house went into a panic and started hunting the bug further. They were able to prove the bug was actually caused by a flaw in Lotus Symphony. So they sued Lotus. Now Lotus went into a panic and started hunting the bug further. They were able to prove the bug was actually in their C compiler. The compiler was generating a short jump when in
Bug #52461 [Asn->Csd]: phpinfo() corrections
Edit report at https://bugs.php.net/bug.php?id=52461&edit=1
ID: 52461
Updated by: paj...@php.net
Reported by:virsacer at web dot de
Summary:phpinfo() corrections
-Status: Assigned
+Status: Closed
Type: Bug
Package:*General Issues
PHP Version:5.3.3
Assigned To:pajoye
Block user comment: N
Private report: N
New Comment:
Thank you for your bug report. This issue has already been fixed
in the latest released version of PHP, which you can download at
http://www.php.net/downloads.php
Previous Comments:
[2011-08-23 00:01:40] neweracracker at gmail dot com
Hi guys,
I guess you did something wrong here:
http://svn.php.net/viewvc/php/php-src/branches/PHP_5_3/ext/standard/info.c?r1=315170&r2=315169&pathrev=315170
Pierre?
PUTS("http://www.w3.org/1999/xhtml\";>>");
should have been:
PUTS("http://www.w3.org/1999/xhtml\";>");
[2011-08-19 10:00:11] paj...@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/.
For Windows:
http://windows.php.net/snapshots/
Thank you for the report, and for helping us make PHP better.
[2011-08-19 09:59:40] paj...@php.net
Automatic comment from SVN on behalf of pajoye
Revision: http://svn.php.net/viewvc/?view=revision&revision=315170
Log: - Fixed bug #52461 (Incomplete doctype and missing xmlns)
[2010-12-08 16:38:11] virsacer at web dot de
"Bug Type" is now bug
[2010-12-08 16:27:06] virsacer at web dot de
New patch contains only bug corrections.
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
https://bugs.php.net/bug.php?id=52461
--
Edit this bug report at https://bugs.php.net/bug.php?id=52461&edit=1
Bug #61267 [Opn->Csd]: pdo_pgsql's PDO::exec() returns the number of SELECTed rows on postgresql >= 9.
Edit report at https://bugs.php.net/bug.php?id=61267&edit=1
ID: 61267
Updated by: cataphr...@php.net
Reported by:ben dot pineau at gmail dot com
Summary:pdo_pgsql's PDO::exec() returns the number of
SELECTed rows on postgresql >= 9.
-Status: Open
+Status: Closed
Type: Bug
Package:PDO related
Operating System: all
PHP Version:Irrelevant
-Assigned To:
+Assigned To:cataphract
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/.
For Windows:
http://windows.php.net/snapshots/
Thank you for the report, and for helping us make PHP better.
Previous Comments:
[2012-03-08 08:52:19] cataphr...@php.net
Automatic comment from SVN on behalf of cataphract
Revision: http://svn.php.net/viewvc/?view=revision&revision=324014
Log: - Fixed bug #61267: pdo_pgsql's PDO::exec() returns the number of SELECTed
rows on postgresql >= 9
[2012-03-03 13:54:09] ben dot pineau at gmail dot com
Description:
After executing a SELECT statement, PDO::exec() -using the pdo_pgsql driver and
running against a PostgreSQL server older than 9.0- will always returns 0, as
does the pdo_mysql and pdo_sqlite drivers. ie. this is the exepected behaviour
(though to be precise, the PDO::exec() documentation stipulate : "PDO::exec()
does not return results from a SELECT statement.").
But when executed against a PostgreSQL >= 9.0 server, this very same php client
and select statement will return the number of selected rows. This is due to a
server side change in how PostgreSQL servers answers to libpqs's PQcmdTuples()
commands (PQcmdTuples() being used as the PDO::exec() return value, via
pdo_pgsql pgsql_handle_doer() function).
This server-side change is visible by comparing this command's documentation
for
different PostgreSQL versions :
http://www.postgresql.org/docs/8.4/interactive/libpq-exec.html#LIBPQ-EXEC-
SELECT-INFO
http://www.postgresql.org/docs/9.1/interactive/libpq-exec.html#LIBPQ-EXEC-
SELECT-INFO
See also the bug in pg_affected_rows https://bugs.php.net/bug.php?id=61266 I
just reported.
The attached patch does check whether the PDO::exec() param was a (successful)
DML statement before using PQcmdTuples() to return the number of affected rows.
Also attached, a test script for PHP's unit test infrastructure.
Test script:
---
// Bugs on PostgreSQL >= 9.0 server (but ok on previous versions)
$dbh = new PDO("pgsql:dbname=postgres ;host=localhost", 'postgres');
var_dump($dbh->exec("SELECT * from generate_series(1, 42);"));
Expected result:
int(0)
Actual result:
--
int(42)
--
Edit this bug report at https://bugs.php.net/bug.php?id=61267&edit=1
Bug #61266 [Opn->Wfx]: pg_affected_rows inconsistent behavior (depends on PostgreSQL server version)
Edit report at https://bugs.php.net/bug.php?id=61266&edit=1
ID: 61266
Updated by: cataphr...@php.net
Reported by:ben dot pineau at gmail dot com
Summary:pg_affected_rows inconsistent behavior (depends on
PostgreSQL server version)
-Status: Open
+Status: Wont fix
Type: Bug
Package:PostgreSQL related
Operating System: all
PHP Version:Irrelevant
Block user comment: N
Private report: N
New Comment:
I don't think PHP should apply compatibility shims on top of libpq, especially
when the new functionality has low impact and actually adds functionality. The
case for your PDO bug report, however, is much more compelling.
Previous Comments:
[2012-03-03 13:42:36] ben dot pineau at gmail dot com
Description:
According to the manual, pg_affected_rows should returns "the number of tuples
(instances/records/rows) affected by INSERT, UPDATE, and DELETE queries.". The
manual details : "The number of rows affected by the query. If no tuple is
affected, it will return 0.".
PHP pg_affected_rows uses libpq's PQcmdTuples() to implement this:
PHP_FUNCTION(pg_affected_rows)
{
php_pgsql_get_result_info(INTERNAL_FUNCTION_PARAM_PASSTHRU,PHP_PG_CMD_TUPLES);
}
static void php_pgsql_get_result_info(INTERNAL_FUNCTION_PARAMETERS, int
entry_type)
{
[...]
case PHP_PG_CMD_TUPLES:
Z_LVAL_P(return_value) = atoi(PQcmdTuples(pgsql_result));
But server's answers to PQcmdTuples() commands changed since PostgreSQL 9.0.
When executed after a SELECT, PostgreSQL < 9.0 returned 0 (as in "0 rows were
affected"); starting with PostgreSQL 9.0, the server returns the number of
SELECTed rows.
See how the PQcmdTuples documentation was updated after pg 9:
http://www.postgresql.org/docs/8.4/interactive/libpq-exec.html#LIBPQ-EXEC-
SELECT-INFO
http://www.postgresql.org/docs/9.1/interactive/libpq-exec.html#LIBPQ-EXEC-
SELECT-INFO
PostgreSQL C API doesn't actually offers a "tell me how many rows were
written/modified" function. But we can restore the previous pg_affected_rows
behavior, and enjoy consistent results no matter which server version we run
against, by unconditionally returning 0 after a SELECT.
This is what the attached patch does, identifying the SELECT with
PQresultStatus() value (which returns PGRES_COMMAND_OK after a successful DML,
as opposed to PGRES_TUPLES_OK after a SELECT, etc).
If you ask so, I can also provide an alternative patch (which tests the string
returned by PQcmdStatus(), a bit ugly imo) and/or an unit test script for PHP's
test framework.
Test script:
---
// Bug on a PostgreSQL >= 9.0 server, ok on older versions.
$dbh = pg_pconnect("dbname=postgres host=localhost user=postgres port=5432");
$q = pg_query($dbh, "SELECT * from generate_series(1, 42);");
var_dump(pg_affected_rows($q));
Expected result:
int(0)
Actual result:
--
int(42)
--
Edit this bug report at https://bugs.php.net/bug.php?id=61266&edit=1
Bug #61321 [Csd->ReO]: Crash on __call + __invoke magic
Edit report at https://bugs.php.net/bug.php?id=61321&edit=1
ID: 61321
Updated by: cataphr...@php.net
Reported by:lol at nrzw dot net
Summary:Crash on __call + __invoke magic
-Status: Closed
+Status: Re-Opened
Type: Bug
Package:Reproducible crash
Operating System: Linux (CentOS, Deb)
PHP Version:5.3.10
Block user comment: N
Private report: N
New Comment:
If it segfaults, there's still a bug. Please don't close it.
Previous Comments:
[2012-03-08 02:58:30] lol at nrzw dot net
@larue...@php.net
I suppose I did =) I don't see how I missed that (I chopped down my code as I
am obviously not working with bags).
I don't see why this would cause a segfault instead of issuing a
failure/warning notice, but that works =) Thank you!
[2012-03-08 02:53:54] larue...@php.net
do you mean like this:
bagone = new bag();
}
public function __call($method, array $args = array()) {
$this->bagone->__invoke($args);
}
}
$c = new bag_container();
$c->bagone('e', array('wtf'));
[2012-03-07 22:07:51] lol at nrzw dot net
Description:
Using PHP versions 5.3.3 up to 5.3.10:
A 'container' has many 'bags', but few methods. Each 'bag' has its own methods
that are callable through it's magic __invoke method. No methods collide with
the properties of the 'container', so one would expect that:
bag_container->bagone('e', array('Some Text'))
Would trigger bag_container's __call (since no method 'bagone' exists in
'bag_container'), which would further trigger the __invoke method in class
'bag'.
Unfortunately, it just creates a segfault =|
I see that there is a related bug
(https://bugs.php.net/bug.php?id=53195&edit=2), but since the bug has not been
updated and this one produces different behavior (segfault), I felt that I
should resubmit. Apologies if that's wrong.
Test script:
---
class bag {
public function e($something) {
echo $something;
}
public function __invoke() {
return call_user_func_array(array($this, $method), $args);
}
}
class bag_container {
public $bagone;
public function __construct() {
$this->bagone = new bag();
}
public function __call($method, array $args = array()) {
return call_user_func_array(array($this, $method), $args);
}
}
$c = new bag_container();
$c->bagone('e', array('wtf'));
Expected result:
One would expect 'wtf' to be echo'd.
Actual result:
--
Segmentation fault.
--
Edit this bug report at https://bugs.php.net/bug.php?id=61321&edit=1
Bug #61287 [Fbk->Csd]: A particular string fails to decompress
Edit report at https://bugs.php.net/bug.php?id=61287&edit=1 ID: 61287 User updated by:yoozer at gmail dot com Reported by:yoozer at gmail dot com Summary:A particular string fails to decompress -Status: Feedback +Status: Closed Type: Bug Package:Zlib related Operating System: * PHP Version:5.4.0 Assigned To:mike Block user comment: N Private report: N New Comment: Mike: I've tested it again on the latest Windows snapshot - 324008 - and the error has disappeared. It's strange how it popped up in r323962 for Windows which should've contained the fix. Anyway - it looks like it works as intended now. Thanks for the quick response! Previous Comments: [2012-03-08 08:00:06] m...@php.net @yoozer can you *really* reproduce that this still fails for you with a current snapshot? It might be Windows-only problem then... [2012-03-07 22:07:25] me at ktamura dot com This has indeed been fixed (tested on OSX) with the snapshot at 323988 [2012-03-07 09:08:44] yoozer at gmail dot com I've tested this script with snapshots 323771 and 323962, but the problem still turns up in both :(. [2012-03-05 15:40:06] m...@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/. For Windows: http://windows.php.net/snapshots/ Thank you for the report, and for helping us make PHP better. [2012-03-05 15:38:16] m...@php.net Automatic comment from SVN on behalf of mike Revision: http://svn.php.net/viewvc/?view=revision&revision=323917 Log: MFH: Fixed bug #61287 (A particular string fails to decompress) 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 https://bugs.php.net/bug.php?id=61287 -- Edit this bug report at https://bugs.php.net/bug.php?id=61287&edit=1
Bug #61287 [Asn->Fbk]: A particular string fails to decompress
Edit report at https://bugs.php.net/bug.php?id=61287&edit=1 ID: 61287 Updated by: m...@php.net Reported by:yoozer at gmail dot com Summary:A particular string fails to decompress -Status: Assigned +Status: Feedback Type: Bug Package:Zlib related Operating System: * PHP Version:5.4.0 Assigned To:mike Block user comment: N Private report: N New Comment: @yoozer can you *really* reproduce that this still fails for you with a current snapshot? It might be Windows-only problem then... Previous Comments: [2012-03-07 22:07:25] me at ktamura dot com This has indeed been fixed (tested on OSX) with the snapshot at 323988 [2012-03-07 09:08:44] yoozer at gmail dot com I've tested this script with snapshots 323771 and 323962, but the problem still turns up in both :(. [2012-03-05 15:40:06] m...@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/. For Windows: http://windows.php.net/snapshots/ Thank you for the report, and for helping us make PHP better. [2012-03-05 15:38:16] m...@php.net Automatic comment from SVN on behalf of mike Revision: http://svn.php.net/viewvc/?view=revision&revision=323917 Log: MFH: Fixed bug #61287 (A particular string fails to decompress) [2012-03-05 15:35:15] m...@php.net Automatic comment from SVN on behalf of mike Revision: http://svn.php.net/viewvc/?view=revision&revision=323916 Log: fix bug #61287 (A particular string fails to decompress) 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 https://bugs.php.net/bug.php?id=61287 -- Edit this bug report at https://bugs.php.net/bug.php?id=61287&edit=1
