#39020 [Opn]: PHP in FastCGI server mode crashes

ID: 39020 User updated by: hugo at leisink dot net Reported By: hugo at leisink dot net Status: Open -Bug Type: Documentation problem +Bug Type: Reproducible crash Operating System: Debian Linux PHP Version: 5.1.6 New Comment: 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. Previous Comments: ------------------------------------------------------------------------ [2006-10-03 12:25:40] 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-03 11:19:50] 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 09:41:16] tony2001@php.net The valgrinds output doesn't show any crash, btw. ------------------------------------------------------------------------ [2006-10-03 09:40:24] 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 07:34:52] 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 ------------------------------------------------------------------------ -- Edit this bug report at http://bugs.php.net/?id=39020&edit=1