[PHP-BUG] Bug #61783 [NEW]: ZipArchive::getStream() crashes php-fcgi (5.3.10)
From:
Operating system: linux
PHP version: 5.3.10
Package: Zip Related
Bug Type: Bug
Bug description:ZipArchive::getStream() crashes php-fcgi (5.3.10)
Description:
When php is running in fcgi mode ZipArchive::getStream() causes PHP to
crash.
Test script:
---
open("/tmp/test.zip",ZIPARCHIVE::CREATE);
$zip->addFromString("test.txt","This is a test");
$zip->close();
unset($zip);
$zip2 = new ZipArchive();
$zip->open("/tmp/test.zip");
$fd = $zip->getStream("test.txt"); // CRASH
?>
Expected result:
Zip to return file handle.
Actual result:
--
PHP Crashes (webserver reports *498 recv() failed (104: Connection reset by
peer)
while reading response header from upstream) and returns 502 Bad Gateway...
--
Edit bug report at https://bugs.php.net/bug.php?id=61783&edit=1
--
Try a snapshot (PHP 5.4):
https://bugs.php.net/fix.php?id=61783&r=trysnapshot54
Try a snapshot (PHP 5.3):
https://bugs.php.net/fix.php?id=61783&r=trysnapshot53
Try a snapshot (trunk):
https://bugs.php.net/fix.php?id=61783&r=trysnapshottrunk
Fixed in SVN:
https://bugs.php.net/fix.php?id=61783&r=fixed
Fixed in SVN and need be documented:
https://bugs.php.net/fix.php?id=61783&r=needdocs
Fixed in release:
https://bugs.php.net/fix.php?id=61783&r=alreadyfixed
Need backtrace:
https://bugs.php.net/fix.php?id=61783&r=needtrace
Need Reproduce Script:
https://bugs.php.net/fix.php?id=61783&r=needscript
Try newer version:
https://bugs.php.net/fix.php?id=61783&r=oldversion
Not developer issue:
https://bugs.php.net/fix.php?id=61783&r=support
Expected behavior:
https://bugs.php.net/fix.php?id=61783&r=notwrong
Not enough info:
https://bugs.php.net/fix.php?id=61783&r=notenoughinfo
Submitted twice:
https://bugs.php.net/fix.php?id=61783&r=submittedtwice
register_globals:
https://bugs.php.net/fix.php?id=61783&r=globals
PHP 4 support discontinued:
https://bugs.php.net/fix.php?id=61783&r=php4
Daylight Savings:https://bugs.php.net/fix.php?id=61783&r=dst
IIS Stability:
https://bugs.php.net/fix.php?id=61783&r=isapi
Install GNU Sed:
https://bugs.php.net/fix.php?id=61783&r=gnused
Floating point limitations:
https://bugs.php.net/fix.php?id=61783&r=float
No Zend Extensions:
https://bugs.php.net/fix.php?id=61783&r=nozend
MySQL Configuration Error:
https://bugs.php.net/fix.php?id=61783&r=mysqlcfg
Bug #61783 [Com]: ZipArchive::getStream() crashes php-fcgi (5.3.10)
Edit report at https://bugs.php.net/bug.php?id=61783&edit=1
ID: 61783
Comment by: james at jamesreno dot com
Reported by:james at jamesreno dot com
Summary:ZipArchive::getStream() crashes php-fcgi (5.3.10)
Status: Open
Type: Bug
Package:Zip Related
Operating System: linux
PHP Version:5.3.10
Block user comment: N
Private report: N
New Comment:
the second two $zip->'s should have been $zip2->'s :( sorry its late (5am)...
Previous Comments:
[2012-04-20 09:08:21] james at jamesreno dot com
Description:
When php is running in fcgi mode ZipArchive::getStream() causes PHP to crash.
Test script:
---
open("/tmp/test.zip",ZIPARCHIVE::CREATE);
$zip->addFromString("test.txt","This is a test");
$zip->close();
unset($zip);
$zip2 = new ZipArchive();
$zip->open("/tmp/test.zip");
$fd = $zip->getStream("test.txt"); // CRASH
?>
Expected result:
Zip to return file handle.
Actual result:
--
PHP Crashes (webserver reports *498 recv() failed (104: Connection reset by
peer)
while reading response header from upstream) and returns 502 Bad Gateway...
--
Edit this bug report at https://bugs.php.net/bug.php?id=61783&edit=1
Bug #61783 [Com]: ZipArchive::getStream() crashes php-fcgi (5.3.10)
Edit report at https://bugs.php.net/bug.php?id=61783&edit=1
ID: 61783
Comment by: james at jamesreno dot com
Reported by:james at jamesreno dot com
Summary:ZipArchive::getStream() crashes php-fcgi (5.3.10)
Status: Feedback
Type: Bug
Package:Zip Related
Operating System: linux
PHP Version:5.3.10
Block user comment: N
Private report: N
New Comment:
This does seem to be fixed in PHP 5.3.11 - it no longer crashes however :( now
dba_fetch() crashes --- yay. On to another bug fixing fiesta!
Regards,
~James
Previous Comments:
[2012-04-29 17:27:14] reeze dot xia at gmail dot com
I ever reproduce it in 5.3.10 but only several times. I can't reproduce it
anymore.
Can you provide more information about the bug? or try lastest version?
[2012-04-22 04:30:56] larue...@php.net
Thank you for this bug report. To properly diagnose the problem, we
need a backtrace to see what is happening behind the scenes. To
find out how to generate a backtrace, please read
http://bugs.php.net/bugs-generating-backtrace.php for *NIX and
http://bugs.php.net/bugs-generating-backtrace-win32.php for Win32
Once you have generated a backtrace, please submit it to this bug
report and change the status back to "Open". Thank you for helping
us make PHP better.
[2012-04-20 09:14:57] james at jamesreno dot com
the second two $zip->'s should have been $zip2->'s :( sorry its late (5am)...
--------
[2012-04-20 09:08:21] james at jamesreno dot com
Description:
When php is running in fcgi mode ZipArchive::getStream() causes PHP to crash.
Test script:
---
open("/tmp/test.zip",ZIPARCHIVE::CREATE);
$zip->addFromString("test.txt","This is a test");
$zip->close();
unset($zip);
$zip2 = new ZipArchive();
$zip->open("/tmp/test.zip");
$fd = $zip->getStream("test.txt"); // CRASH
?>
Expected result:
Zip to return file handle.
Actual result:
--
PHP Crashes (webserver reports *498 recv() failed (104: Connection reset by
peer)
while reading response header from upstream) and returns 502 Bad Gateway...
--
Edit this bug report at https://bugs.php.net/bug.php?id=61783&edit=1
Bug #61783 [Fbk->Csd]: ZipArchive::getStream() crashes php-fcgi (5.3.10)
Edit report at https://bugs.php.net/bug.php?id=61783&edit=1
ID: 61783
User updated by:james at jamesreno dot com
Reported by:james at jamesreno dot com
Summary:ZipArchive::getStream() crashes php-fcgi (5.3.10)
-Status: Feedback
+Status: Closed
Type: Bug
Package:Zip Related
Operating System: linux
PHP Version:5.3.10
Block user comment: N
Private report: N
New Comment:
Fixed in PHP 5.3.11 (no longer crashes).
Previous Comments:
[2012-05-01 02:26:47] james at jamesreno dot com
This does seem to be fixed in PHP 5.3.11 - it no longer crashes however :( now
dba_fetch() crashes --- yay. On to another bug fixing fiesta!
Regards,
~James
[2012-04-29 17:27:14] reeze dot xia at gmail dot com
I ever reproduce it in 5.3.10 but only several times. I can't reproduce it
anymore.
Can you provide more information about the bug? or try lastest version?
[2012-04-22 04:30:56] larue...@php.net
Thank you for this bug report. To properly diagnose the problem, we
need a backtrace to see what is happening behind the scenes. To
find out how to generate a backtrace, please read
http://bugs.php.net/bugs-generating-backtrace.php for *NIX and
http://bugs.php.net/bugs-generating-backtrace-win32.php for Win32
Once you have generated a backtrace, please submit it to this bug
report and change the status back to "Open". Thank you for helping
us make PHP better.
[2012-04-20 09:14:57] james at jamesreno dot com
the second two $zip->'s should have been $zip2->'s :( sorry its late (5am)...
--------
[2012-04-20 09:08:21] james at jamesreno dot com
Description:
When php is running in fcgi mode ZipArchive::getStream() causes PHP to crash.
Test script:
---
open("/tmp/test.zip",ZIPARCHIVE::CREATE);
$zip->addFromString("test.txt","This is a test");
$zip->close();
unset($zip);
$zip2 = new ZipArchive();
$zip->open("/tmp/test.zip");
$fd = $zip->getStream("test.txt"); // CRASH
?>
Expected result:
Zip to return file handle.
Actual result:
--
PHP Crashes (webserver reports *498 recv() failed (104: Connection reset by
peer)
while reading response header from upstream) and returns 502 Bad Gateway...
--
Edit this bug report at https://bugs.php.net/bug.php?id=61783&edit=1
[PHP-BUG] Bug #61885 [NEW]: dba_fetch() segfaults with db-4.8
From: Operating system: Linux-2.6 / CentOS 5.8 PHP version: 5.3.11 Package: DBM/DBA related Bug Type: Bug Bug description:dba_fetch() segfaults with db-4.8 Description: When using dba_fetch with a db4 database a segfault is generated and php crashes. Important Notes: We use db48 rpm from ZeroC for IcePHP Support. At the time of testing we did not have the IcePHP.so loaded to ensure that it was not a conflict with that module. dba.so is linked against this db4 rpm: http://www.zeroc.com/download/Ice/3.4/rhel5/x86_64/db48-devel-4.8.30- 1ice.rhel5.x86_64.rpm [root@web2 ~]# ldd /usr/local/php/lib/php/extensions/no-debug-non-zts- 20090626/dba.so linux-vdso.so.1 => (0x7fff62deb000) libdb-4.8.so => /usr/lib64/libdb-4.8.so (0x2b024cad9000) libc.so.6 => /lib64/libc.so.6 (0x2b024ce43000) libpthread.so.0 => /lib64/libpthread.so.0 (0x2b024d19b000) /lib64/ld-linux-x86-64.so.2 (0x2b024c6a3000) Test script: --- ?> Expected result: PHP to return the fetched dba result Actual result: -- Segfault Program received signal SIGSEGV, Segmentation fault. 0x0171f190 in ?? () (gdb) bt #0 0x0171f190 in ?? () #1 0x2aaab1a347a6 in dba_exists_db4 (info=0x16ed090, key=, keylen=) at /usr/src/redhat/BUILD/lsgphp-1.0.6/php-5.3.11/ext/dba/dba_db4.c:211 #2 0x2aaab1a33c48 in zif_dba_exists (ht=, return_value=0x16d1318, return_value_ptr=, this_ptr=, return_value_used=) at /usr/src/redhat/BUILD/lsgphp-1.0.6/php-5.3.11/ext/dba/dba.c:984 #3 0x006e9bf9 in zend_do_fcall_common_helper_SPEC () #4 0x006e8d4e in execute () #5 0x006c2459 in zend_execute_scripts () #6 0x0066f0c8 in php_execute_script () #7 0x0074b27e in main () -- Edit bug report at https://bugs.php.net/bug.php?id=61885&edit=1 -- Try a snapshot (PHP 5.4): https://bugs.php.net/fix.php?id=61885&r=trysnapshot54 Try a snapshot (PHP 5.3): https://bugs.php.net/fix.php?id=61885&r=trysnapshot53 Try a snapshot (trunk): https://bugs.php.net/fix.php?id=61885&r=trysnapshottrunk Fixed in SVN: https://bugs.php.net/fix.php?id=61885&r=fixed Fixed in SVN and need be documented: https://bugs.php.net/fix.php?id=61885&r=needdocs Fixed in release: https://bugs.php.net/fix.php?id=61885&r=alreadyfixed Need backtrace: https://bugs.php.net/fix.php?id=61885&r=needtrace Need Reproduce Script: https://bugs.php.net/fix.php?id=61885&r=needscript Try newer version: https://bugs.php.net/fix.php?id=61885&r=oldversion Not developer issue: https://bugs.php.net/fix.php?id=61885&r=support Expected behavior: https://bugs.php.net/fix.php?id=61885&r=notwrong Not enough info: https://bugs.php.net/fix.php?id=61885&r=notenoughinfo Submitted twice: https://bugs.php.net/fix.php?id=61885&r=submittedtwice register_globals: https://bugs.php.net/fix.php?id=61885&r=globals PHP 4 support discontinued: https://bugs.php.net/fix.php?id=61885&r=php4 Daylight Savings:https://bugs.php.net/fix.php?id=61885&r=dst IIS Stability: https://bugs.php.net/fix.php?id=61885&r=isapi Install GNU Sed: https://bugs.php.net/fix.php?id=61885&r=gnused Floating point limitations: https://bugs.php.net/fix.php?id=61885&r=float No Zend Extensions: https://bugs.php.net/fix.php?id=61885&r=nozend MySQL Configuration Error: https://bugs.php.net/fix.php?id=61885&r=mysqlcfg
Bug #61885 [Com]: dba_fetch() segfaults with db-4.8
Edit report at https://bugs.php.net/bug.php?id=61885&edit=1
ID: 61885
Comment by: james at jamesreno dot com
Reported by:james at jamesreno dot com
Summary:dba_fetch() segfaults with db-4.8
Status: Open
Type: Bug
Package:DBM/DBA related
Operating System: Linux-2.6 / CentOS 5.8
PHP Version:5.3.11
Block user comment: N
Private report: N
New Comment:
dba_fetch() and dba_exists() are the same function under the hood, with
different return values. I noticed my example said dba_exists() while the
subject said dba_fetch()...
Both functions crash/segfault at the same code:
dba_fetch(): line 172: if (!dba->dbp->get(dba->dbp, NULL, &gkey, &gval, 0)) {
dba_exists():line 211: if (!dba->dbp->get(dba->dbp, NULL, &gkey, &gval, 0)) {
I am not sure how to debug this any further. would this indicate a problem in
the db4 library or php? I am (probably wrongfully) assuming it has something
to
do with the way the gkey and gval are passed by reference.
I am not sure what frame 0 is in the stack trace - gdb was not very useful here
-- most likely its the actual dba->dbp "get"...
One additional note:
While we do use the rpm provided by ZeroC after further research it seems to
simply be an UNMODIFIED version of the db-4.8.30.NC tarball provided by Oracle.
Potentially the BDB API changed between 4.3 and 4.8 resulting in the segfult
when get() is called?
Previous Comments:
----------------
[2012-05-01 03:41:07] james at jamesreno dot com
Description:
When using dba_fetch with a db4 database a segfault is generated and php
crashes.
Important Notes:
We use db48 rpm from ZeroC for IcePHP Support. At the time of testing we did
not
have the IcePHP.so loaded to ensure that it was not a conflict with that module.
dba.so is linked against this db4 rpm:
http://www.zeroc.com/download/Ice/3.4/rhel5/x86_64/db48-devel-4.8.30-
1ice.rhel5.x86_64.rpm
[root@web2 ~]# ldd /usr/local/php/lib/php/extensions/no-debug-non-zts-
20090626/dba.so
linux-vdso.so.1 => (0x7fff62deb000)
libdb-4.8.so => /usr/lib64/libdb-4.8.so (0x2b024cad9000)
libc.so.6 => /lib64/libc.so.6 (0x2b024ce43000)
libpthread.so.0 => /lib64/libpthread.so.0 (0x2b024d19b000)
/lib64/ld-linux-x86-64.so.2 (0x2b024c6a3000)
Test script:
---
?>
Expected result:
PHP to return the fetched dba result
Actual result:
--
Segfault
Program received signal SIGSEGV, Segmentation fault.
0x0171f190 in ?? ()
(gdb) bt
#0 0x0171f190 in ?? ()
#1 0x2aaab1a347a6 in dba_exists_db4 (info=0x16ed090, key=, keylen=)
at /usr/src/redhat/BUILD/lsgphp-1.0.6/php-5.3.11/ext/dba/dba_db4.c:211
#2 0x2aaab1a33c48 in zif_dba_exists (ht=,
return_value=0x16d1318, return_value_ptr=,
this_ptr=, return_value_used=)
at /usr/src/redhat/BUILD/lsgphp-1.0.6/php-5.3.11/ext/dba/dba.c:984
#3 0x006e9bf9 in zend_do_fcall_common_helper_SPEC ()
#4 0x006e8d4e in execute ()
#5 0x006c2459 in zend_execute_scripts ()
#6 0x0066f0c8 in php_execute_script ()
#7 0x0074b27e in main ()
--
Edit this bug report at https://bugs.php.net/bug.php?id=61885&edit=1
#48104 [NEW]: PHP FD-Leak - FastCGI + auto_prepend
From: james at jamesreno dot com Operating system: Debian 5.0.1 (lenny); 2.6.26-2-a PHP version: 5.2.9 PHP Bug Type: Unknown/Other Function Bug description: PHP FD-Leak - FastCGI + auto_prepend Description: PHP leaks file descriptors by not closing the requested file at the end of request. See: http://pastebin.com/m3edccacf *** REGARDLESS of suhosin being enabled/compiled or disable and NOT patched, the same problem appears. I have removed suhosin from php and yet the issue still appears. Please dont just "blame suhosin" and ignore this fact. No third-party modules are enabled - apc has been disabled & uninstalled as well. This seems like an off-by-one somewhere in relation to the auto_prepend. removing the auto_prepend statement from the php.ini fixes the problem. Reproduce code: --- Request http://127.0.0.1/somescript.php auto_prepend_file = "/tmp/test.php"; #/tmp/test.php #/tmp/test2.php #/var/www/html/somescript.php echo " world"; Expected result: Output of "hello World"; and PHP should close all of its files it opened. Actual result: -- Output is proper. PHP opens: 1) /tmp/test.php 2) /tmp/test2.php 3) /var/www/html/somescript.php however, php only closes: 1) /tmp/test.php 2) /tmp/test2.php it does NOT close 3) /var/www/html/somescript.php -- Edit bug report at http://bugs.php.net/?id=48104&edit=1 -- Try a CVS snapshot (PHP 5.2): http://bugs.php.net/fix.php?id=48104&r=trysnapshot52 Try a CVS snapshot (PHP 5.3): http://bugs.php.net/fix.php?id=48104&r=trysnapshot53 Try a CVS snapshot (PHP 6.0): http://bugs.php.net/fix.php?id=48104&r=trysnapshot60 Fixed in CVS: http://bugs.php.net/fix.php?id=48104&r=fixedcvs Fixed in CVS and need be documented: http://bugs.php.net/fix.php?id=48104&r=needdocs Fixed in release: http://bugs.php.net/fix.php?id=48104&r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=48104&r=needtrace Need Reproduce Script: http://bugs.php.net/fix.php?id=48104&r=needscript Try newer version: http://bugs.php.net/fix.php?id=48104&r=oldversion Not developer issue: http://bugs.php.net/fix.php?id=48104&r=support Expected behavior: http://bugs.php.net/fix.php?id=48104&r=notwrong Not enough info: http://bugs.php.net/fix.php?id=48104&r=notenoughinfo Submitted twice: http://bugs.php.net/fix.php?id=48104&r=submittedtwice register_globals: http://bugs.php.net/fix.php?id=48104&r=globals PHP 4 support discontinued: http://bugs.php.net/fix.php?id=48104&r=php4 Daylight Savings:http://bugs.php.net/fix.php?id=48104&r=dst IIS Stability: http://bugs.php.net/fix.php?id=48104&r=isapi Install GNU Sed: http://bugs.php.net/fix.php?id=48104&r=gnused Floating point limitations: http://bugs.php.net/fix.php?id=48104&r=float No Zend Extensions: http://bugs.php.net/fix.php?id=48104&r=nozend MySQL Configuration Error: http://bugs.php.net/fix.php?id=48104&r=mysqlcfg
#48104 [Com]: PHP FD-Leak - FastCGI + auto_prepend
ID: 48104 Comment by: james at jamesreno dot com Reported By: james at jamesreno dot com Status: Open Bug Type: Unknown/Other Function Operating System: Debian 5.0.1 (lenny); 2.6.26-2-a PHP Version: 5.2.9 New Comment: strace of the pid is also now included -- i forgot to include it in the previous pastebin url. http://pastebin.com/mc72a99b Previous Comments: [2009-04-29 07:59:49] james at jamesreno dot com Description: PHP leaks file descriptors by not closing the requested file at the end of request. See: http://pastebin.com/m3edccacf *** REGARDLESS of suhosin being enabled/compiled or disable and NOT patched, the same problem appears. I have removed suhosin from php and yet the issue still appears. Please dont just "blame suhosin" and ignore this fact. No third-party modules are enabled - apc has been disabled & uninstalled as well. This seems like an off-by-one somewhere in relation to the auto_prepend. removing the auto_prepend statement from the php.ini fixes the problem. Reproduce code: --- Request http://127.0.0.1/somescript.php auto_prepend_file = "/tmp/test.php"; #/tmp/test.php #/tmp/test2.php #/var/www/html/somescript.php echo " world"; Expected result: Output of "hello World"; and PHP should close all of its files it opened. Actual result: -- Output is proper. PHP opens: 1) /tmp/test.php 2) /tmp/test2.php 3) /var/www/html/somescript.php however, php only closes: 1) /tmp/test.php 2) /tmp/test2.php it does NOT close 3) /var/www/html/somescript.php -- Edit this bug report at http://bugs.php.net/?id=48104&edit=1
#48104 [Com]: PHP FD-Leak - FastCGI + auto_prepend
ID: 48104 Comment by: james at jamesreno dot com Reported By: james at jamesreno dot com Status: Open Bug Type: Unknown/Other Function Operating System: Debian 5.0.1 (lenny); 2.6.26-2-a PHP Version: 5.2.9 New Comment: [*** NOT TESTED - DO NOT USE ***] After spending countless hours trying to determine where php is leaking the file descriptors as mentioned in the post. It looks like zend_destroy_file_handle in Zend/zend_language_scanner.c is missing a call to zend_file_handle_dtor on file_handler. If you add zend_file_handle_dtor(file_handle); it would seem the issue would be fixed. Is this proper - or is there some reason that zend_destroy_file_handle does not call the destructor zend_file_handle_dtor Previous Comments: [2009-04-29 08:18:06] james at jamesreno dot com strace of the pid is also now included -- i forgot to include it in the previous pastebin url. http://pastebin.com/mc72a99b [2009-04-29 07:59:49] james at jamesreno dot com Description: PHP leaks file descriptors by not closing the requested file at the end of request. See: http://pastebin.com/m3edccacf *** REGARDLESS of suhosin being enabled/compiled or disable and NOT patched, the same problem appears. I have removed suhosin from php and yet the issue still appears. Please dont just "blame suhosin" and ignore this fact. No third-party modules are enabled - apc has been disabled & uninstalled as well. This seems like an off-by-one somewhere in relation to the auto_prepend. removing the auto_prepend statement from the php.ini fixes the problem. Reproduce code: --- Request http://127.0.0.1/somescript.php auto_prepend_file = "/tmp/test.php"; #/tmp/test.php #/tmp/test2.php #/var/www/html/somescript.php echo " world"; Expected result: Output of "hello World"; and PHP should close all of its files it opened. Actual result: -- Output is proper. PHP opens: 1) /tmp/test.php 2) /tmp/test2.php 3) /var/www/html/somescript.php however, php only closes: 1) /tmp/test.php 2) /tmp/test2.php it does NOT close 3) /var/www/html/somescript.php -- Edit this bug report at http://bugs.php.net/?id=48104&edit=1
#48104 [Com]: PHP FD-Leak - FastCGI + auto_prepend
ID: 48104 Comment by: james at jamesreno dot com Reported By: james at jamesreno dot com Status: Open Bug Type: Unknown/Other Function Operating System: Debian 5.0.1 (lenny); 2.6.26-2-a PHP Version: 5.2.9 New Comment: Problem still persists. I have not yet found solution to resolve this problem. More Information: This leak only happens in fastCGI mode (-b). It seems that the leak only happens in a subset of files on the server, not every file, but i can not find anything in those files other than the fact that they are larger than the rest (ie: more code). They do not use any weird extensions or special crazy syntax. I tried to compile with --disable-all --enable-fastcgi, and the problem persists. I was NOT able to re-produce with the "CGI" binary, stracing shows that php does indeed close the file. Only with -b and running in fastCGI mode does the PHP leak the FD's. PHP-fcgi is started like so: su -m -c "nohup env PHP_FCGI_CHILDREN=5 PHP_FCGI_MAX_REQUESTS=1000 bin/php-fcgi-spawn -b 127.0.0.1:8081 -d 'error_log=$PHP_ERRLOG' >> $FCGI_LOG 2>&1 &" apache Is there anything else you can think of trying? The suggestion i provided in my previous comment, just causes glibc to segfault php with "glibc detected !prev". In what file is the original file FD closed when executing via FCGI. I notice that the other included files are being closed properly, but just not the main executed .php. Previous Comments: ---------------- [2009-04-29 17:00:05] james at jamesreno dot com [*** NOT TESTED - DO NOT USE ***] After spending countless hours trying to determine where php is leaking the file descriptors as mentioned in the post. It looks like zend_destroy_file_handle in Zend/zend_language_scanner.c is missing a call to zend_file_handle_dtor on file_handler. If you add zend_file_handle_dtor(file_handle); it would seem the issue would be fixed. Is this proper - or is there some reason that zend_destroy_file_handle does not call the destructor zend_file_handle_dtor ---------------- [2009-04-29 08:18:06] james at jamesreno dot com strace of the pid is also now included -- i forgot to include it in the previous pastebin url. http://pastebin.com/mc72a99b ---------------- [2009-04-29 07:59:49] james at jamesreno dot com Description: PHP leaks file descriptors by not closing the requested file at the end of request. See: http://pastebin.com/m3edccacf *** REGARDLESS of suhosin being enabled/compiled or disable and NOT patched, the same problem appears. I have removed suhosin from php and yet the issue still appears. Please dont just "blame suhosin" and ignore this fact. No third-party modules are enabled - apc has been disabled & uninstalled as well. This seems like an off-by-one somewhere in relation to the auto_prepend. removing the auto_prepend statement from the php.ini fixes the problem. Reproduce code: --- Request http://127.0.0.1/somescript.php auto_prepend_file = "/tmp/test.php"; #/tmp/test.php #/tmp/test2.php #/var/www/html/somescript.php echo " world"; Expected result: Output of "hello World"; and PHP should close all of its files it opened. Actual result: -- Output is proper. PHP opens: 1) /tmp/test.php 2) /tmp/test2.php 3) /var/www/html/somescript.php however, php only closes: 1) /tmp/test.php 2) /tmp/test2.php it does NOT close 3) /var/www/html/somescript.php -- Edit this bug report at http://bugs.php.net/?id=48104&edit=1
#48104 [Com]: FD-Leak - FastCGI + auto_prepend
ID: 48104 Comment by: james at jamesreno dot com Reported By: james at jamesreno dot com Status: Feedback Bug Type: CGI related Operating System: Debian 5.0.1 (lenny); 2.6.26-2-a PHP Version: 5.2.9 New Comment: The php5.3-200904291830 snapshot worked - yes. I am not for sure what causes this in 5.2.9 but 5.3 fixes the problem. I generally dont like running beta/rc software in production however looks like this is my only choice currently. Any ideas what could cause this issue? Previous Comments: [2009-04-30 08:30:41] j...@php.net Please try using this CVS snapshot: http://snaps.php.net/php5.3-latest.tar.gz For Windows: http://windows.php.net/snapshots/ [2009-04-29 21:53:54] james at jamesreno dot com Problem still persists. I have not yet found solution to resolve this problem. More Information: This leak only happens in fastCGI mode (-b). It seems that the leak only happens in a subset of files on the server, not every file, but i can not find anything in those files other than the fact that they are larger than the rest (ie: more code). They do not use any weird extensions or special crazy syntax. I tried to compile with --disable-all --enable-fastcgi, and the problem persists. I was NOT able to re-produce with the "CGI" binary, stracing shows that php does indeed close the file. Only with -b and running in fastCGI mode does the PHP leak the FD's. PHP-fcgi is started like so: su -m -c "nohup env PHP_FCGI_CHILDREN=5 PHP_FCGI_MAX_REQUESTS=1000 bin/php-fcgi-spawn -b 127.0.0.1:8081 -d 'error_log=$PHP_ERRLOG' >> $FCGI_LOG 2>&1 &" apache Is there anything else you can think of trying? The suggestion i provided in my previous comment, just causes glibc to segfault php with "glibc detected !prev". In what file is the original file FD closed when executing via FCGI. I notice that the other included files are being closed properly, but just not the main executed .php. ---------------- [2009-04-29 17:00:05] james at jamesreno dot com [*** NOT TESTED - DO NOT USE ***] After spending countless hours trying to determine where php is leaking the file descriptors as mentioned in the post. It looks like zend_destroy_file_handle in Zend/zend_language_scanner.c is missing a call to zend_file_handle_dtor on file_handler. If you add zend_file_handle_dtor(file_handle); it would seem the issue would be fixed. Is this proper - or is there some reason that zend_destroy_file_handle does not call the destructor zend_file_handle_dtor ---------------- [2009-04-29 08:18:06] james at jamesreno dot com strace of the pid is also now included -- i forgot to include it in the previous pastebin url. http://pastebin.com/mc72a99b ---------------- [2009-04-29 07:59:49] james at jamesreno dot com Description: PHP leaks file descriptors by not closing the requested file at the end of request. See: http://pastebin.com/m3edccacf *** REGARDLESS of suhosin being enabled/compiled or disable and NOT patched, the same problem appears. I have removed suhosin from php and yet the issue still appears. Please dont just "blame suhosin" and ignore this fact. No third-party modules are enabled - apc has been disabled & uninstalled as well. This seems like an off-by-one somewhere in relation to the auto_prepend. removing the auto_prepend statement from the php.ini fixes the problem. Reproduce code: --- Request http://127.0.0.1/somescript.php auto_prepend_file = "/tmp/test.php"; #/tmp/test.php #/tmp/test2.php #/var/www/html/somescript.php echo " world"; Expected result: Output of "hello World"; and PHP should close all of its files it opened. Actual result: -- Output is proper. PHP opens: 1) /tmp/test.php 2) /tmp/test2.php 3) /var/www/html/somescript.php however, php only closes: 1) /tmp/test.php 2) /tmp/test2.php it does NOT close 3) /var/www/html/somescript.php -- Edit this bug report at http://bugs.php.net/?id=48104&edit=1
#47566 [Bgs]: PCNTL Waitpid exit status incorrect
ID: 47566
User updated by: james at jamesreno dot com
Reported By: james at jamesreno dot com
Status: Bogus
Bug Type: PCNTL related
Operating System: linux-2.6
PHP Version: 5.2.9
New Comment:
Not bogus see below:
Its obviously not returning properly:
1. while (($pid=pcntl_waitpid(-1,$status,WNOHANG))>0) {
2. echo "RAW: {$status}\n";
3. var_dump(pcntl_wifexited($status));
4.var_dump(pcntl_wexitstatus($status));
5. var_dump(pcntl_wifsignaled($status));
6.var_dump(pcntl_wtermsig($status));
7. var_dump(pcntl_wifstopped($status));
8.var_dump(pcntl_wstopsig($status));
9. echo "END RAW: {$status}\n";
10. }
11.
12. RAW: 65280
13. pcntl_wifexited == bool(true) => pcntl_wexitstatus ==
int(-1)
14. pcntl_wifsignaled == bool(false) => pcntl_wtermsig==
int(0)
15. pcntl_wifstopped == bool(false) => pcntl_wstopsig==
int(255)
16. END RAW: 65280
17.
18.
19. RAW: 65280
20. bool(true)
21. int(-1)
22. bool(false)
23. int(0)
24. bool(false)
25. int(255)
26. END RAW: 65280
Guess ill be hax0ring the code to make it work properly.
seems the same on PHP 5.3.0-RC2
Previous Comments:
----
[2009-03-05 20:54:53] james at jamesreno dot com
exit(254);
$pid = pcntl_waitpid(-1,$status);
if (pcntl_wifexited($status)) {
$status = pcntl_wexitstatus($status);
echo $status;
}
Then why is $status, -2 rather than '254'?
This method does not seem work *properly* either...
[2009-03-04 23:11:46] fel...@php.net
You need to use the pcntl_wexitstatus().
http://docs.php.net/manual/en/function.pcntl-wexitstatus.php
http://www.mkssoftware.com/docs/man3/waitpid.3.asp
--------
[2009-03-04 21:59:01] james at jamesreno dot com
Description:
The $status exitcode returned by pcntl_waitpid() is incorrectly casted
resulting in an invalid number being returned.
I believe the int is converted to a long in ext/pcntl/pcntl.c,
resulting in an invalid integer being returned to the parent.
zval *z_status = NULL;
int status;
convert_to_long_ex(&z_status);
status = Z_LVAL_P(z_status);
child_id = waitpid((pid_t) pid, &status, options);
Z_LVAL_P(z_status) = status;
z_status is a long, but status is an int...
Reproduce code:
---
Expected result:
[ja...@localhost ~]$ php test.php
CHILD: Exiting with exit code 128
PARENT: 7598/7598 exited 128
[ja...@localhost ~]$ echo $?
128
[ja...@localhost ~]$
Actual result:
--
[ja...@localhost ~]$ php test.php
CHILD: Exiting with exit code 128
PARENT: 7598/7598 exited 32768
[ja...@localhost ~]$ echo $?
128
[ja...@localhost ~]$
--
Edit this bug report at http://bugs.php.net/?id=47566&edit=1
#47566 [Bgs]: PCNTL Waitpid exit status incorrect
ID: 47566
User updated by: james at jamesreno dot com
Reported By: james at jamesreno dot com
Status: Bogus
Bug Type: PCNTL related
Operating System: linux-2.6
PHP Version: 5.2.9
New Comment:
/* {{{ proto int pcntl_wexitstatus(int status)
Returns the status code of a child's exit */
PHP_FUNCTION(pcntl_wexitstatus)
The function definition says it returns an INT, as it SHOULD -- exit
codes can not be negative! and are in the range of 0-255 (8 bits) on
posix systems. (iirc).
-- HOWEVER --
Php actually returns:
status_word = (int) Z_LVAL_PP(status);
/* WEXITSTATUS only returns 8 bits so we *MUST* cast this to
signed char
if you want to have valid negative exit codes */
RETURN_LONG((signed char) WEXITSTATUS(status_word));
It should NOT, it should not cast it to a (signed char)
So if you actually want the right result in your code :(
In php-5.2.9/ext/pcntl/pcntl.c line 379
Change:
RETURN_LONG((signed char) WEXITSTATUS(status_word));
to:
RETURN_LONG(WEXITSTATUS(status_word));
Previous Comments:
[2009-05-26 04:47:50] james at jamesreno dot com
Not bogus see below:
Its obviously not returning properly:
1. while (($pid=pcntl_waitpid(-1,$status,WNOHANG))>0) {
2. echo "RAW: {$status}\n";
3. var_dump(pcntl_wifexited($status));
4.var_dump(pcntl_wexitstatus($status));
5. var_dump(pcntl_wifsignaled($status));
6.var_dump(pcntl_wtermsig($status));
7. var_dump(pcntl_wifstopped($status));
8.var_dump(pcntl_wstopsig($status));
9. echo "END RAW: {$status}\n";
10. }
11.
12. RAW: 65280
13. pcntl_wifexited == bool(true) => pcntl_wexitstatus ==
int(-1)
14. pcntl_wifsignaled == bool(false) => pcntl_wtermsig==
int(0)
15. pcntl_wifstopped == bool(false) => pcntl_wstopsig==
int(255)
16. END RAW: 65280
17.
18.
19. RAW: 65280
20. bool(true)
21. int(-1)
22. bool(false)
23. int(0)
24. bool(false)
25. int(255)
26. END RAW: 65280
Guess ill be hax0ring the code to make it work properly.
seems the same on PHP 5.3.0-RC2
--------
[2009-03-05 20:54:53] james at jamesreno dot com
exit(254);
$pid = pcntl_waitpid(-1,$status);
if (pcntl_wifexited($status)) {
$status = pcntl_wexitstatus($status);
echo $status;
}
Then why is $status, -2 rather than '254'?
This method does not seem work *properly* either...
[2009-03-04 23:11:46] fel...@php.net
You need to use the pcntl_wexitstatus().
http://docs.php.net/manual/en/function.pcntl-wexitstatus.php
http://www.mkssoftware.com/docs/man3/waitpid.3.asp
------------
[2009-03-04 21:59:01] james at jamesreno dot com
Description:
The $status exitcode returned by pcntl_waitpid() is incorrectly casted
resulting in an invalid number being returned.
I believe the int is converted to a long in ext/pcntl/pcntl.c,
resulting in an invalid integer being returned to the parent.
zval *z_status = NULL;
int status;
convert_to_long_ex(&z_status);
status = Z_LVAL_P(z_status);
child_id = waitpid((pid_t) pid, &status, options);
Z_LVAL_P(z_status) = status;
z_status is a long, but status is an int...
Reproduce code:
---
Expected result:
[ja...@localhost ~]$ php test.php
CHILD: Exiting with exit code 128
PARENT: 7598/7598 exited 128
[ja...@localhost ~]$ echo $?
128
[ja...@localhost ~]$
Actual result:
--
[ja...@localhost ~]$ php test.php
CHILD: Exiting with exit code 128
PARENT: 7598/7598 exited 32768
[ja...@localhost ~]$ echo $?
128
[ja...@localhost ~]$
--
Edit this bug report at http://bugs.php.net/?id=47566&edit=1
#47566 [NEW]: PCNTL Waitpid exit status incorrect
From: james at jamesreno dot com Operating system: linux-2.6 PHP version: 5.2.9 PHP Bug Type: PCNTL related Bug description: PCNTL Waitpid exit status incorrect Description: The $status exitcode returned by pcntl_waitpid() is incorrectly casted resulting in an invalid number being returned. I believe the int is converted to a long in ext/pcntl/pcntl.c, resulting in an invalid integer being returned to the parent. zval *z_status = NULL; int status; convert_to_long_ex(&z_status); status = Z_LVAL_P(z_status); child_id = waitpid((pid_t) pid, &status, options); Z_LVAL_P(z_status) = status; z_status is a long, but status is an int... Reproduce code: --- Expected result: [ja...@localhost ~]$ php test.php CHILD: Exiting with exit code 128 PARENT: 7598/7598 exited 128 [ja...@localhost ~]$ echo $? 128 [ja...@localhost ~]$ Actual result: -- [ja...@localhost ~]$ php test.php CHILD: Exiting with exit code 128 PARENT: 7598/7598 exited 32768 [ja...@localhost ~]$ echo $? 128 [ja...@localhost ~]$ -- Edit bug report at http://bugs.php.net/?id=47566&edit=1 -- Try a CVS snapshot (PHP 5.2): http://bugs.php.net/fix.php?id=47566&r=trysnapshot52 Try a CVS snapshot (PHP 5.3): http://bugs.php.net/fix.php?id=47566&r=trysnapshot53 Try a CVS snapshot (PHP 6.0): http://bugs.php.net/fix.php?id=47566&r=trysnapshot60 Fixed in CVS: http://bugs.php.net/fix.php?id=47566&r=fixedcvs Fixed in CVS and need be documented: http://bugs.php.net/fix.php?id=47566&r=needdocs Fixed in release: http://bugs.php.net/fix.php?id=47566&r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=47566&r=needtrace Need Reproduce Script: http://bugs.php.net/fix.php?id=47566&r=needscript Try newer version: http://bugs.php.net/fix.php?id=47566&r=oldversion Not developer issue: http://bugs.php.net/fix.php?id=47566&r=support Expected behavior: http://bugs.php.net/fix.php?id=47566&r=notwrong Not enough info: http://bugs.php.net/fix.php?id=47566&r=notenoughinfo Submitted twice: http://bugs.php.net/fix.php?id=47566&r=submittedtwice register_globals: http://bugs.php.net/fix.php?id=47566&r=globals PHP 4 support discontinued: http://bugs.php.net/fix.php?id=47566&r=php4 Daylight Savings:http://bugs.php.net/fix.php?id=47566&r=dst IIS Stability: http://bugs.php.net/fix.php?id=47566&r=isapi Install GNU Sed: http://bugs.php.net/fix.php?id=47566&r=gnused Floating point limitations: http://bugs.php.net/fix.php?id=47566&r=float No Zend Extensions: http://bugs.php.net/fix.php?id=47566&r=nozend MySQL Configuration Error: http://bugs.php.net/fix.php?id=47566&r=mysqlcfg
#47566 [Bgs]: PCNTL Waitpid exit status incorrect
ID: 47566
User updated by: james at jamesreno dot com
Reported By: james at jamesreno dot com
Status: Bogus
Bug Type: PCNTL related
Operating System: linux-2.6
PHP Version: 5.2.9
New Comment:
exit(254);
$pid = pcntl_waitpid(-1,$status);
if (pcntl_wifexited($status)) {
$status = pcntl_wexitstatus($status);
echo $status;
}
Then why is $status, -2 rather than '254'?
This method does not seem work *properly* either...
Previous Comments:
[2009-03-04 23:11:46] fel...@php.net
You need to use the pcntl_wexitstatus().
http://docs.php.net/manual/en/function.pcntl-wexitstatus.php
http://www.mkssoftware.com/docs/man3/waitpid.3.asp
[2009-03-04 21:59:01] james at jamesreno dot com
Description:
The $status exitcode returned by pcntl_waitpid() is incorrectly casted
resulting in an invalid number being returned.
I believe the int is converted to a long in ext/pcntl/pcntl.c,
resulting in an invalid integer being returned to the parent.
zval *z_status = NULL;
int status;
convert_to_long_ex(&z_status);
status = Z_LVAL_P(z_status);
child_id = waitpid((pid_t) pid, &status, options);
Z_LVAL_P(z_status) = status;
z_status is a long, but status is an int...
Reproduce code:
---
Expected result:
[ja...@localhost ~]$ php test.php
CHILD: Exiting with exit code 128
PARENT: 7598/7598 exited 128
[ja...@localhost ~]$ echo $?
128
[ja...@localhost ~]$
Actual result:
--
[ja...@localhost ~]$ php test.php
CHILD: Exiting with exit code 128
PARENT: 7598/7598 exited 32768
[ja...@localhost ~]$ echo $?
128
[ja...@localhost ~]$
--
Edit this bug report at http://bugs.php.net/?id=47566&edit=1
[PHP-BUG] Bug #54186 [NEW]: Scope Resolution / Closure Class Issues
From:
Operating system: Linux-2.6
PHP version: 5.3.5
Package: Class/Object related
Bug Type: Bug
Bug description:Scope Resolution / Closure Class Issues
Description:
closure objects which are members of another object can not be executed
without
temp intermediary variables and constants of objects can not be accessed
when
they are members of another object.
I can not find any documentation to support why these two items throw
syntax
errors rather than executing as expected. At very least case this is a
documentation issue and should be noted.
Test script:
---
callback = $callback;
$this->test = new apples();
}
}
$a = new test(function(){
echo "test\n";
});
/*
* Broken Closure Class Example
*/
// BROKEN:
$a->callback();
// Works
$tmp = $a->callback;
$tmp();
/*
* Broken constant scope resolution
*/
// BROKEN:
$a->test::test;
// Works
$tmp = $a->test;
echo $tmp::test;
?>
Expected result:
Would expect:
$a->callback() to execute the anonymous function.
would expect:
echo $a->test::test to echo "This is a test"
Actual result:
--
Both references cause syntax errors.
--
Edit bug report at http://bugs.php.net/bug.php?id=54186&edit=1
--
Try a snapshot (PHP 5.2):
http://bugs.php.net/fix.php?id=54186&r=trysnapshot52
Try a snapshot (PHP 5.3):
http://bugs.php.net/fix.php?id=54186&r=trysnapshot53
Try a snapshot (trunk):
http://bugs.php.net/fix.php?id=54186&r=trysnapshottrunk
Fixed in SVN:
http://bugs.php.net/fix.php?id=54186&r=fixed
Fixed in SVN and need be documented:
http://bugs.php.net/fix.php?id=54186&r=needdocs
Fixed in release:
http://bugs.php.net/fix.php?id=54186&r=alreadyfixed
Need backtrace:
http://bugs.php.net/fix.php?id=54186&r=needtrace
Need Reproduce Script:
http://bugs.php.net/fix.php?id=54186&r=needscript
Try newer version:
http://bugs.php.net/fix.php?id=54186&r=oldversion
Not developer issue:
http://bugs.php.net/fix.php?id=54186&r=support
Expected behavior:
http://bugs.php.net/fix.php?id=54186&r=notwrong
Not enough info:
http://bugs.php.net/fix.php?id=54186&r=notenoughinfo
Submitted twice:
http://bugs.php.net/fix.php?id=54186&r=submittedtwice
register_globals:
http://bugs.php.net/fix.php?id=54186&r=globals
PHP 4 support discontinued: http://bugs.php.net/fix.php?id=54186&r=php4
Daylight Savings:http://bugs.php.net/fix.php?id=54186&r=dst
IIS Stability:
http://bugs.php.net/fix.php?id=54186&r=isapi
Install GNU Sed:
http://bugs.php.net/fix.php?id=54186&r=gnused
Floating point limitations:
http://bugs.php.net/fix.php?id=54186&r=float
No Zend Extensions:
http://bugs.php.net/fix.php?id=54186&r=nozend
MySQL Configuration Error:
http://bugs.php.net/fix.php?id=54186&r=mysqlcfg
Bug #54186 [Bgs]: Scope Resolution / Closure Class Issues
Edit report at http://bugs.php.net/bug.php?id=54186&edit=1
ID: 54186
User updated by:james at jamesreno dot com
Reported by:james at jamesreno dot com
Summary:Scope Resolution / Closure Class Issues
Status: Bogus
Type: Bug
Package:Class/Object related
Operating System: Linux-2.6
PHP Version:5.3.5
Block user comment: N
Private report: N
New Comment:
"the other is a mere grammatical issue." Would you care to explain?
To me these features seem half implemented which mean they are bugs --
not
feature requests. The language already supports said items just not in
"certain
contexts" (To which should be noted in documentation, at very least).
At least
change this to a documentation bug - do not close it as "bogus" the bug
is
clearly NOT bogus as it indeed is real and does affect the language and
usage
there-of -- "WONT FIX" is more like it.
Anyone can close bugs as bogus and put some b.s. response. I spent the
time to
detail out the issue and document it clearly it would be nice if you
could at
least spend the same effort responding to it.
Previous Comments:
[2011-03-09 11:10:43] cataphr...@php.net
$a->callback(); not working a problem of executing callbacks in fields
not being supported (there's a RFC proposing that), the other is a mere
grammatical issue.
Closing; if anything this would be a feature request, but in that case
the two issues ought to be filled separately, as they're unrelated.
----------------
[2011-03-07 20:59:11] james at jamesreno dot com
Description:
closure objects which are members of another object can not be executed
without
temp intermediary variables and constants of objects can not be accessed
when
they are members of another object.
I can not find any documentation to support why these two items throw
syntax
errors rather than executing as expected. At very least case this is a
documentation issue and should be noted.
Test script:
---
callback = $callback;
$this->test = new apples();
}
}
$a = new test(function(){
echo "test\n";
});
/*
* Broken Closure Class Example
*/
// BROKEN:
$a->callback();
// Works
$tmp = $a->callback;
$tmp();
/*
* Broken constant scope resolution
*/
// BROKEN:
$a->test::test;
// Works
$tmp = $a->test;
echo $tmp::test;
?>
Expected result:
Would expect:
$a->callback() to execute the anonymous function.
would expect:
echo $a->test::test to echo "This is a test"
Actual result:
--
Both references cause syntax errors.
--
Edit this bug report at http://bugs.php.net/bug.php?id=54186&edit=1
