php.net |  support |  documentation |  report a bug |  advanced search |  search howto |  statistics |  random bug |  login

go to bug id or search bugs for

Bug #39020 PHP in FastCGI server mode crashes
Submitted: 2006-10-03 07:34 UTC Modified: 2006-10-16 10:48 UTC
Votes:3
Avg. Score:4.3 ± 0.5
Reproduced:3 of 3 (100.0%)
Same Version:1 (33.3%)
Same OS:2 (66.7%)
From: hugo at leisink dot net Assigned: dmitry (profile)
Status: Closed Package: Reproducible crash
PHP Version: 5.1.6 OS: Debian Linux
Private report: No CVE-ID: None
View Developer Edit
 [2006-10-03 07:34 UTC] hugo at leisink dot net 
Description:
------------
If PHP is started as a FastCGI server, it crashes when a large amount of request are being send. I used /usr/sbin/ab -n 10000 -c 10 <URL> to stresstest it. It crashes after about 3000 requests.

Reproduce code:
---------------
Start PHP as a FastCGI server. Configure a FastCGI-enabled webserver. Use /usr/sbin/ab -n 10000 -c 10 <URL> to stress-test it. PHP will crash after a few thousand requests.

Expected result:
----------------
No crash....

Actual result:
--------------
Valgrind output:

==13767== Memcheck, a memory error detector for x86-linux.
==13767== Copyright (C) 2002-2005, and GNU GPL'd, by Julian Seward et al.
==13767== Using valgrind-2.4.0, a program supervision framework for x86-linux.
==13767== Copyright (C) 2000-2005, and GNU GPL'd, by Julian Seward et al.
==13767== For more details, rerun with: -v
==13767==
==13767==
==13767== ERROR SUMMARY: 0 errors from 0 contexts (suppressed: 100 from 3)
==13767== malloc/free: in use at exit: 19166 bytes in 1225 blocks.
==13767== malloc/free: 898027 allocs, 896802 frees, 340213828 bytes allocated.
==13767== For counts of detected errors, rerun with: -v
==13767== searching for pointers to 1225 not-freed blocks.
==13767== checked 1415844 bytes.
==13767==
==13767== 4 bytes in 1 blocks are definitely lost in loss record 1 of 7
==13767==    at 0x1B90459D: malloc (vg_replace_malloc.c:130)
==13767==    by 0x1B8E9346: (within /lib/ld-2.3.2.so)
==13767==    by 0x1B8EA5A5: _dl_map_object (in /lib/ld-2.3.2.so)
==13767==    by 0x1B8EEB08: (within /lib/ld-2.3.2.so)
==13767==    by 0x1B8F0015: _dl_catch_error (in /lib/ld-2.3.2.so)
==13767==    by 0x1B8EF580: _dl_map_object_deps (in /lib/ld-2.3.2.so)
==13767==    by 0x1BF61EDF: (within /lib/libc-2.3.2.so)
==13767==    by 0x1B8F0015: _dl_catch_error (in /lib/ld-2.3.2.so)
==13767==    by 0x1BF62675: _dl_open (in /lib/libc-2.3.2.so)
==13767==    by 0x1BF639B2: (within /lib/libc-2.3.2.so)
==13767==    by 0x1B8F0015: _dl_catch_error (in /lib/ld-2.3.2.so)
==13767==    by 0x1BF6396D: (within /lib/libc-2.3.2.so)
==13767==
==13767==
==13767== 54 bytes in 2 blocks are definitely lost in loss record 4 of 7
==13767==    at 0x1B90459D: malloc (vg_replace_malloc.c:130)
==13767==    by 0x1C388F81: ???
==13767==    by 0x1C388E4A: ???
==13767==    by 0x1C35AFC1: ???
==13767==    by 0x1C352128: ???
==13767==    by 0x1C2F4995: ???
==13767==    by 0x1C2F4B0A: ???
==13767==    by 0x1C2F349E: ???
==13767==    by 0x1C2F3729: ???
==13767==    by 0x1BF472A3: getprotobyname_r (in /lib/libc-2.3.2.so)
==13767==    by 0x1BF4714E: getprotobyname (in /lib/libc-2.3.2.so)
==13767==    by 0x81C1E2D: zm_startup_sockets (in /usr/bin/php5-cgi)
==13767==
==13767== LEAK SUMMARY:
==13767==    definitely lost: 58 bytes in 3 blocks.
==13767==      possibly lost: 0 bytes in 0 blocks.
==13767==    still reachable: 19108 bytes in 1222 blocks.
==13767==         suppressed: 0 bytes in 0 blocks.
==13767== Reachable blocks (those to which a pointer was found) are not shown.
==13767== To see them, rerun with: --show-reachable=yes

Patches

Pull Requests

History

AllCommentsChangesGit/SVN commitsRelated reports
 [2006-10-03 09:40 UTC] tony2001@php.net 
Please try using this CVS snapshot:

  http://snaps.php.net/php5.2-latest.tar.gz
 
For Windows:
 
  http://snaps.php.net/win32/php5.2-win32-latest.zip
 [2006-10-03 09:41 UTC] tony2001@php.net 
The valgrinds output doesn't show any crash, btw.
 [2006-10-03 11:19 UTC] hugo at leisink dot net 
5.2.0RC5-dev also quits/crashes. I agree that Valgrind doesn't show any crash. But the result is the same: PHP stops running.  I'm trying real hard to find out what is happing or what causes PHP to quit/crash. It looks like it's random. Somethings it stops after 100 requests, somethings after 5000. 

I'm using Debian sarge, which comes with PHP 4.3.10. This version has the same problem.

I'm writing my own webserver and I'm now implementing FastCGI support. So, it is possible that my webserver doesn't send the right FastCGI commands/record information. But if so, it shouldn't make PHP to stop running.
 [2006-10-03 12:25 UTC] hugo at leisink dot net 
Ok, I've got something interesting. I've been digging through the source and found the statement PHP_FCGI_MAX_REQUESTS. I've found the file /sapi/cgi/README.FastCGI, which says some things about the environment settings PHP_FCGI_CHILDREN and PHP_FCGI_MAX_REQUESTS. I'm running PHP now with 5 children and everything looks oke (Don't close this bugreport yet, please. Wanna do some more tests first). It even survived several stresstests with 'ab'.

But now I have this question: Why is this important (read: necessary) information NOT in the manualpage!?!?!
 [2006-10-07 06:50 UTC] hugo at leisink dot net 
New problem: for some of my sites, I got FastCGI working. For some sites not. PHP dumps a 200MB core file in /tmp. I think we really got a crash here.
 [2006-10-11 09:19 UTC] tony2001@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.
 [2006-10-11 09:47 UTC] hugo at leisink dot net 
#0  0x4028daff in memcpy () from /lib/libc.so.6
#1  0x082343d9 in zend_strndup (s=0xe485454 <Address 0xe485454 out of bounds>, length=3221225471)
    at /usr/src/php/php5.2-200610030830/Zend/zend_alloc.c:1779
#2  0x082adaa3 in fcgi_get_params (req=0xe485454,
    p=0xbffedc20 "P_COOKIEpma_collation_connection=utf8_unicode_ci; pma_lang=en-iso-8859-1; pma_charset=iso-8859-1; pma_cookie_username-1=wckGFw8uHyROd%2Bz3D6DaiQ%3D%3D", end=0xbffedcb6 "")
    at /usr/src/php/php5.2-200610030830/sapi/cgi/fastcgi.c:422
#3  0x082ae092 in fcgi_read_request (req=0xbfffdc20) at /usr/src/php/php5.2-200610030830/sapi/cgi/fastcgi.c:506
#4  0x082ae673 in fcgi_accept_request (req=0xbfffdc20) at /usr/src/php/php5.2-200610030830/sapi/cgi/fastcgi.c:703
#5  0x082b042b in main (argc=3, argv=0xbffffd24) at /usr/src/php/php5.2-200610030830/sapi/cgi/cgi_main.c:1361
 [2006-10-16 10:48 UTC] dmitry@php.net 
The bug is fixed in CVS HEAD and PHP_5_2.
 
PHP Copyright © 2001-2024 The PHP Group
All rights reserved. 		Last updated: Sat Dec 21 14:01:32 2024 UTC