Bug #60961 [Asn]: Graceful Restart (USR2) isn't very graceful
Edit report at https://bugs.php.net/bug.php?id=60961edit=1
ID: 60961
User updated by:phpbugs at oops dot mooo dot com
Reported by:phpbugs at oops dot mooo dot com
Summary:Graceful Restart (USR2) isn't very graceful
Status: Assigned
Type: Bug
Package:FPM related
Operating System: Debian Squeeze
PHP Version:5.3.9
Assigned To:fat
Block user comment: N
Private report: N
New Comment:
Try setting process_control_timeout to something higher than 0.
Previous Comments:
[2013-02-13 09:47:32] php-bugs at puzzled dot xs4all dot nl
CentOS 6.3 with php-5.3.3 and the FPM code from 5.3.20 still has the same
issue. FWIW this makes it challenging to use nginx with php-fpm because it
results in a 502 Bad Gateway. I'm more than happy to help testing a patch.
[2012-07-17 06:40:44] megazubr at gmail dot com
Centos 5.8, php 5.4.4 compiled from source with --enable-fpm
When doing USR2 on master pid of php-fpm daemon
1. kill child(502 Bad gatway on long_loop.php in same time)
2. restart daemon with another master pid
As i see, it's not a graceful reload.
master pid - 12788
child(long_loop.php) - 12795
strace -f -s 8000 -p 12788
[pid 12795] munmap(0x2b017edd1000, 1168) = 0
[pid 12795] munmap(0x2b017edd2000, 1168) = 0
[pid 12795] munmap(0x2b017edd3000, 1168) = 0
[pid 12795] munmap(0x2b017edb5000, 112) = 0
[pid 12795] time(NULL) = 1342505962
[pid 12795] dup2(1, 2) = 2
[pid 12795] close(4)= 0
[pid 12795] dup2(13, 0) = 0
[pid 12795] geteuid() = 0
[pid 12795] setgid(500) = 0
[pid 12795] open(/proc/sys/kernel/ngroups_max, O_RDONLY) = 4
[pid 12795] read(4, 65536\n, 31) = 6
[pid 12795] close(4)= 0
[pid 12795] open(/etc/group, O_RDONLY) = 4
[pid 12795] fcntl(4, F_GETFD) = 0
[pid 12795] fcntl(4, F_SETFD, FD_CLOEXEC) = 0
[pid 12795] fstat(4, {st_mode=S_IFREG|0644, st_size=693, ...}) = 0
[pid 12795] mmap(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS,
-1, 0) = 0x2b017b3ce000
[pid 12795] lseek(4, 0, SEEK_CUR) = 0
[pid 12795] read(4,
root:x:0:root\nbin:x:1:root,bin,daemon\ndaemon:x:2:root,bin,daemon\nsys:x:3:roo
t,bin,adm\nadm:x:4:root,adm,daemon\ntty:x:5:\ndisk:x:6:root\nlp:x:7:daemon,lp\nm
em:x:8:\nkmem:x:9:\nwheel:x:10:root\nmail:x:12:mail,exim\nnews:x:13:news\nuucp:x
:14:uucp\nman:x:15:\ngames:x:20:\ngopher:x:30:\ndip:x:40:\nftp:x:50:\nlock:x:54:
\nnobody:x:99:\nusers:x:100:\nnscd:x:28:\nfloppy:x:19:\nvcsa:x:69:\npcap:x:77:\n
utmp:x:22:\nutempter:x:35:\nslocate:x:21:\naudio:x:63:\nrpc:x:32:\nmailnull:x:47
:\nsmmsp:x:51:\necryptfs:x:101:\nsshd:x:74:\ndbus:x:81:\navahi:x:70:\nrpcuser:x:
29:\nnfsnobody:x:65534:\nhaldaemon:x:68:\navahi-
autoipd:x:102:\nmysql:x:27:\nftpgroup:x:107:\nexim:x:93:\nscreen:x:84:\nfwh:x:50
0:\nqwqwqw:x:501:\n1q2w3e:x:502:\n1q:x:503:\n2w:x:504:\n, 4096) = 693
[pid 12795] read(4, , 4096) = 0
[pid 12795] close(4)= 0
[pid 12795] munmap(0x2b017b3ce000, 4096) = 0
[pid 12795] setgroups(1, [500]) = 0
[pid 12795] setuid(500) = 0
[pid 12795] prctl(0x4, 0x1, 0, 0, 0)= 0
[pid 12795] clock_gettime(CLOCK_MONOTONIC, {1029872, 690313456}) = 0
[pid 12795] close(6)= 0
[pid 12795] close(8)= 0
[pid 12795] rt_sigaction(SIGTERM, {SIG_DFL, [], SA_RESTORER, 0x322c6302f0},
NULL, 8) = 0
[pid 12795] rt_sigaction(SIGINT, {SIG_DFL, [], SA_RESTORER, 0x322c6302f0},
NULL,
8) = 0
[pid 12795] rt_sigaction(SIGUSR1, {SIG_DFL, [], SA_RESTORER, 0x322c6302f0},
NULL, 8) = 0
[pid 12795] rt_sigaction(SIGUSR2, {SIG_DFL, [], SA_RESTORER, 0x322c6302f0},
NULL, 8) = 0
[pid 12795] rt_sigaction(SIGCHLD, {SIG_DFL, [], SA_RESTORER, 0x322c6302f0},
NULL, 8) = 0
[pid 12795] rt_sigaction(SIGQUIT, {0x7c33f0, [], SA_RESTORER|SA_RESTART,
0x322c6302f0}, NULL, 8) = 0
[pid 12795] close(9)= 0
[pid 12795] close(10) = 0
[pid 12795] close(11) = 0
[pid 12795] close(12) = 0
[pid 12795] close(13) = 0
[pid 12795] clock_gettime(CLOCK_MONOTONIC, {1029872, 692338456}) = 0
[pid 12795] accept(0, {sa_family=AF_INET, sin_port=htons(60781),
sin_addr=inet_addr(127.0.0.1)}, [16]) = 4
[pid 12795] clock_gettime(CLOCK_MONOTONIC, {1029872, 692611456}) = 0
[pid 12795] time(NULL) = 1342505962
[pid 12795] times({tms_utime=0, tms_stime=0, tms_cutime=0, tms_cstime=0}) =
1821051559
[pid 12795] poll([{fd=4, events=POLLIN}], 1, 5000) = 1 ([{fd=4,
revents=POLLIN}])
[pid 12795] read(4, \1\1\0\1\0\10\0\0, 8) = 8
[pid 12795] read(4, \0\1\0\0\0\0\0\0, 8) = 8
[pid 12795] read(4, \1\4\0\1\4\313\5\0, 8) = 8
[pid 12795] read(4,
\17'SCRIPT_FILENAME/home/_htdocs/public_html
Bug #61067 [Com]: free() from signal handler leads to deadlock
Edit report at https://bugs.php.net/bug.php?id=61067edit=1 ID: 61067 Comment by: phpbugs at oops dot mooo dot com Reported by:phpbugs at oops dot mooo dot com Summary:free() from signal handler leads to deadlock Status: Open Type: Bug Package:FPM related Operating System: Debian Squeeze PHP Version:5.3.10 Block user comment: N Private report: N New Comment: You're correct it looks like the same bug. Sorry for not searching well enough. Previous Comments: [2012-02-14 12:11:21] jpa...@php.net Seems related to #31749 [2012-02-12 22:59:18] phpbugs at oops dot mooo dot com Description: Using PHP-FPM-5.3.10+APC-3.1.9. I just discovered 30 PHP processes that's been running for 22 hours. Further inspection revealed all of them (except one) are waiting to flock() a session file. The process holding the flock() is doing: futex(0x7f21238f9e40, FUTEX_WAIT_PRIVATE, 2, NULL unfinished ... (gdb) info threads Id Target Id Frame * 1Thread 0x7f2126114720 (LWP 4271) __lll_lock_wait_private () at ../nptl/sysdeps/unix/sysv/linux/x86_64/lowlevellock.S:97 (gdb) bt #0 __lll_lock_wait_private () at ../nptl/sysdeps/unix/sysv/linux/x86_64/lowlevellock.S:97 #1 0x7f2123614558 in _L_lock_9590 () from /lib/libc.so.6 #2 0x7f2123612941 in *__GI___libc_free (mem=0x7f21238f9e40) at malloc.c:3737 #3 0x7f21263f5820 in php_error_cb (type=1, error_filename=0x7f2121088fd8 , error_lineno=154, format=optimized out, args=optimized out) at /build/php-5.3.10/main/main.c:931 #4 0x7f2126446d7c in zend_error (type=1, format=0x7f2126902028 Maximum execution time of %d second%s exceeded) at /build/php-5.3.10/Zend/zend.c:1127 #5 signal handler called #6 0x7f2123612a1d in *__GI___libc_malloc (bytes=50) at malloc.c:3658 #7 0x7f2123617a22 in *__GI___strdup (s=0x7f2121088fd8 ) at strdup.c:43 #8 0x7f21263f587a in php_error_cb (type=8, error_filename=0x7f2121088fd8 , error_lineno=154, format=optimized out, args=optimized out) at /build/php-5.3.10/main/main.c:943 #9 0x7f2126446d7c in zend_error (type=8, format=0x7f2126907356 Undefined index: %s) at /build/php-5.3.10/Zend/zend.c:1127 #10 0x7f21264b2f89 in zend_fetch_dimension_address_inner (type=optimized out, dim=optimized out, ht=optimized out) at /build/php-5.3.10/Zend/zend_execute.c:820 #11 zend_fetch_dimension_address_read (result=0x7f2127f17930, container_ptr=optimized out, dim=0x7f2126bf25c8, dim_is_tmp_var=optimized out, type=0) at /build/php-5.3.10/Zend/zend_execute.c:1043 #12 0x7f21264b4059 in ZEND_FETCH_DIM_R_SPEC_CV_VAR_HANDLER (execute_data=0x7f2127f17678) at /build/php-5.3.10/Zend/zend_vm_execute.h:26962 #13 0x7f212646ee30 in execute (op_array=0x7f2127efe020) at /build/php-5.3.10/Zend/zend_vm_execute.h:107 #14 0x7f212644654f in zend_execute_scripts (type=8, retval=optimized out, file_count=3) at /build/php-5.3.10/Zend/zend.c:1308 #15 0x7f21263f2bc7 in php_execute_script (primary_file=optimized out) at /build/php-5.3.10/main/main.c:2323 #16 0x7f21264db7c8 in main (argc=669766600, argv=optimized out) at /build/php-5.3.10/sapi/fpm/fpm/fpm_main.c:1875 It looks like PHP caught a signal inside malloc(), causing glibc to take some lock, and that free() wants the same lock, leading to deadlock. I'm not sure if malloc/free is safe to use in signal handlers. http://linux.derkeiler.com/Newsgroups/comp.os.linux.development.apps/2005-07/0323.html seems to suggest it's not. -- Edit this bug report at https://bugs.php.net/bug.php?id=61067edit=1
[PHP-BUG] Bug #61067 [NEW]: free() from signal handler leads to deadlock
From: Operating system: Debian Squeeze PHP version: 5.3.10 Package: FPM related Bug Type: Bug Bug description:free() from signal handler leads to deadlock Description: Using PHP-FPM-5.3.10+APC-3.1.9. I just discovered 30 PHP processes that's been running for 22 hours. Further inspection revealed all of them (except one) are waiting to flock() a session file. The process holding the flock() is doing: futex(0x7f21238f9e40, FUTEX_WAIT_PRIVATE, 2, NULL unfinished ... (gdb) info threads Id Target Id Frame * 1Thread 0x7f2126114720 (LWP 4271) __lll_lock_wait_private () at ../nptl/sysdeps/unix/sysv/linux/x86_64/lowlevellock.S:97 (gdb) bt #0 __lll_lock_wait_private () at ../nptl/sysdeps/unix/sysv/linux/x86_64/lowlevellock.S:97 #1 0x7f2123614558 in _L_lock_9590 () from /lib/libc.so.6 #2 0x7f2123612941 in *__GI___libc_free (mem=0x7f21238f9e40) at malloc.c:3737 #3 0x7f21263f5820 in php_error_cb (type=1, error_filename=0x7f2121088fd8 , error_lineno=154, format=optimized out, args=optimized out) at /build/php-5.3.10/main/main.c:931 #4 0x7f2126446d7c in zend_error (type=1, format=0x7f2126902028 Maximum execution time of %d second%s exceeded) at /build/php-5.3.10/Zend/zend.c:1127 #5 signal handler called #6 0x7f2123612a1d in *__GI___libc_malloc (bytes=50) at malloc.c:3658 #7 0x7f2123617a22 in *__GI___strdup (s=0x7f2121088fd8 ) at strdup.c:43 #8 0x7f21263f587a in php_error_cb (type=8, error_filename=0x7f2121088fd8 , error_lineno=154, format=optimized out, args=optimized out) at /build/php-5.3.10/main/main.c:943 #9 0x7f2126446d7c in zend_error (type=8, format=0x7f2126907356 Undefined index: %s) at /build/php-5.3.10/Zend/zend.c:1127 #10 0x7f21264b2f89 in zend_fetch_dimension_address_inner (type=optimized out, dim=optimized out, ht=optimized out) at /build/php-5.3.10/Zend/zend_execute.c:820 #11 zend_fetch_dimension_address_read (result=0x7f2127f17930, container_ptr=optimized out, dim=0x7f2126bf25c8, dim_is_tmp_var=optimized out, type=0) at /build/php-5.3.10/Zend/zend_execute.c:1043 #12 0x7f21264b4059 in ZEND_FETCH_DIM_R_SPEC_CV_VAR_HANDLER (execute_data=0x7f2127f17678) at /build/php-5.3.10/Zend/zend_vm_execute.h:26962 #13 0x7f212646ee30 in execute (op_array=0x7f2127efe020) at /build/php-5.3.10/Zend/zend_vm_execute.h:107 #14 0x7f212644654f in zend_execute_scripts (type=8, retval=optimized out, file_count=3) at /build/php-5.3.10/Zend/zend.c:1308 #15 0x7f21263f2bc7 in php_execute_script (primary_file=optimized out) at /build/php-5.3.10/main/main.c:2323 #16 0x7f21264db7c8 in main (argc=669766600, argv=optimized out) at /build/php-5.3.10/sapi/fpm/fpm/fpm_main.c:1875 It looks like PHP caught a signal inside malloc(), causing glibc to take some lock, and that free() wants the same lock, leading to deadlock. I'm not sure if malloc/free is safe to use in signal handlers. http://linux.derkeiler.com/Newsgroups/comp.os.linux.development.apps/2005-07/0323.html seems to suggest it's not. -- Edit bug report at https://bugs.php.net/bug.php?id=61067edit=1 -- Try a snapshot (PHP 5.4): https://bugs.php.net/fix.php?id=61067r=trysnapshot54 Try a snapshot (PHP 5.3): https://bugs.php.net/fix.php?id=61067r=trysnapshot53 Try a snapshot (trunk): https://bugs.php.net/fix.php?id=61067r=trysnapshottrunk Fixed in SVN: https://bugs.php.net/fix.php?id=61067r=fixed Fixed in SVN and need be documented: https://bugs.php.net/fix.php?id=61067r=needdocs Fixed in release: https://bugs.php.net/fix.php?id=61067r=alreadyfixed Need backtrace: https://bugs.php.net/fix.php?id=61067r=needtrace Need Reproduce Script: https://bugs.php.net/fix.php?id=61067r=needscript Try newer version: https://bugs.php.net/fix.php?id=61067r=oldversion Not developer issue: https://bugs.php.net/fix.php?id=61067r=support Expected behavior: https://bugs.php.net/fix.php?id=61067r=notwrong Not enough info: https://bugs.php.net/fix.php?id=61067r=notenoughinfo Submitted twice: https://bugs.php.net/fix.php?id=61067r=submittedtwice register_globals: https://bugs.php.net/fix.php?id=61067r=globals PHP 4 support discontinued: https://bugs.php.net/fix.php?id=61067r=php4 Daylight Savings:https://bugs.php.net/fix.php?id=61067r=dst IIS Stability: https://bugs.php.net/fix.php?id=61067r=isapi Install GNU Sed: https://bugs.php.net/fix.php?id=61067r=gnused Floating point limitations: https://bugs.php.net/fix.php?id=61067r=float No Zend Extensions: https://bugs.php.net/fix.php?id=61067r=nozend MySQL Configuration Error: https://bugs.php.net/fix.php?id=61067r=mysqlcfg
[PHP-BUG] Bug #60961 [NEW]: Graceful Restart (USR2) isn't very graceful
From: Operating system: Debian Squeeze PHP version: 5.3.9 Package: FPM related Bug Type: Bug Bug description:Graceful Restart (USR2) isn't very graceful Description: I just compiled a new PHP+APC with the CVE-2012-0830 fix. It looks like all/some of the the active requests died. I had the same problem when upgrading to 5.3.8 and 5.3.9 too. # cat /var/log/nginx/error.log *empty* # cat /var/run/php-fpm.pid 2161 # ps aux | fgrep -i 2161 root 2161 0.1 0.2 123692 4520 ?Ss 06:28 0:00 php-fpm: master process (/opt/php/etc/php-fpm.conf) # kill -USR2 2161 # cat /var/log/nginx/error.log 2012/02/02 21:08:26 [error] 25004#0: *7381002 recv() failed (104: Connection reset by peer) while reading response header from upstream, client: XXX 2012/02/02 21:08:26 [error] 25004#0: *7381001 recv() failed (104: Connection reset by peer) while reading response header from upstream, client: XXX 2012/02/02 21:08:26 [error] 25004#0: *7372696 recv() failed (104: Connection reset by peer) while reading response header from upstream, client: XXX 2012/02/02 21:08:26 [error] 25004#0: *7381238 recv() failed (104: Connection reset by peer) while reading response header from upstream, client: XXX 2012/02/02 21:08:26 [error] 25004#0: *7374985 recv() failed (104: Connection reset by peer) while reading response header from upstream, client: XXX 2012/02/02 21:08:26 [error] 25004#0: *7369723 recv() failed (104: Connection reset by peer) while reading response header from upstream, client: XXX 2012/02/02 21:08:26 [error] 25004#0: *7360478 recv() failed (104: Connection reset by peer) while reading response header from upstream, client: XXX 2012/02/02 21:08:26 [error] 25004#0: *7371999 recv() failed (104: Connection reset by peer) while reading response header from upstream, client: XXX 2012/02/02 21:08:26 [error] 25004#0: *7375111 recv() failed (104: Connection reset by peer) while reading response header from upstream, client: XXX 2012/02/02 21:08:26 [error] 25004#0: *7381000 readv() failed (104: Connection reset by peer) while reading upstream, client: xx.xx.xx.xx, server: XXX This gives 502 Bad Gateway on the client. -- Edit bug report at https://bugs.php.net/bug.php?id=60961edit=1 -- Try a snapshot (PHP 5.4): https://bugs.php.net/fix.php?id=60961r=trysnapshot54 Try a snapshot (PHP 5.3): https://bugs.php.net/fix.php?id=60961r=trysnapshot53 Try a snapshot (trunk): https://bugs.php.net/fix.php?id=60961r=trysnapshottrunk Fixed in SVN: https://bugs.php.net/fix.php?id=60961r=fixed Fixed in SVN and need be documented: https://bugs.php.net/fix.php?id=60961r=needdocs Fixed in release: https://bugs.php.net/fix.php?id=60961r=alreadyfixed Need backtrace: https://bugs.php.net/fix.php?id=60961r=needtrace Need Reproduce Script: https://bugs.php.net/fix.php?id=60961r=needscript Try newer version: https://bugs.php.net/fix.php?id=60961r=oldversion Not developer issue: https://bugs.php.net/fix.php?id=60961r=support Expected behavior: https://bugs.php.net/fix.php?id=60961r=notwrong Not enough info: https://bugs.php.net/fix.php?id=60961r=notenoughinfo Submitted twice: https://bugs.php.net/fix.php?id=60961r=submittedtwice register_globals: https://bugs.php.net/fix.php?id=60961r=globals PHP 4 support discontinued: https://bugs.php.net/fix.php?id=60961r=php4 Daylight Savings:https://bugs.php.net/fix.php?id=60961r=dst IIS Stability: https://bugs.php.net/fix.php?id=60961r=isapi Install GNU Sed: https://bugs.php.net/fix.php?id=60961r=gnused Floating point limitations: https://bugs.php.net/fix.php?id=60961r=float No Zend Extensions: https://bugs.php.net/fix.php?id=60961r=nozend MySQL Configuration Error: https://bugs.php.net/fix.php?id=60961r=mysqlcfg
Bug #60629 [Com]: memory corruption when web server closed the fcgi fd(?)
Edit report at https://bugs.php.net/bug.php?id=60629edit=1 ID: 60629 Comment by: phpbugs at oops dot mooo dot com Reported by:phpbugs at oops dot mooo dot com Summary:memory corruption when web server closed the fcgi fd(?) Status: Feedback Type: Bug Package:FPM related Operating System: Debian Squeeze PHP Version:5.3.9RC4 Assigned To:fat Block user comment: N Private report: N New Comment: Looks good to me, I don't understand a) Why was fcgi_write's return value changed to ssize_t b) Why the explicit (size_t) casts was added but I can't see any problem with them either :) (I only did this part.) - size_t ret; + ssize_t ret Previous Comments: [2012-01-03 18:03:28] f...@php.net Can you please test and validate the attached patch please ? thx ++ jerome [2012-01-03 18:02:55] f...@php.net The following patch has been added/updated: Patch Name: fpm-bugs-60629.patch Revision: 1325613774 URL: https://bugs.php.net/patch-display.php?bug=60629patch=fpm-bugs-60629.patchrevision=1325613774 [2012-01-03 12:13:34] f...@php.net it's on my todo list. I'll try to take time to look at this bugs this week. ++ jerome [2012-01-03 12:12:09] larue...@php.net fat, could you plz look at this? thanks [2011-12-30 23:40:43] phpbugs at oops dot mooo dot com I think it might've been introduced in this commit (~line 270). http://svn.php.net/viewvc/php/php-src/tags/php_5_3_9RC4/sapi/fpm/fpm/fpm_main.c?r1=317894r2=317897 It looks like write() might have the same problem, since it returns a ssize_t that's casted to size_t. Fix might be to use ssize_t instead? 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=60629 -- Edit this bug report at https://bugs.php.net/bug.php?id=60629edit=1
[PHP-BUG] Bug #60629 [NEW]: memory corruption when web server closed the fcgi fd(?)
From:
Operating system: Debian Squeeze
PHP version: 5.3.9RC4
Package: FPM related
Bug Type: Bug
Bug description:memory corruption when web server closed the fcgi fd(?)
Description:
I tried php5.3.9RC4 today and got a few core dumps.
I think b)fcgi_flush() returns false, making fcgi_write return -1. Then
sapi_cgibin_single_write will make it positive because ret is unsigned in
c). As a result, the comparison in d) will fail.
In debugger it looks like PHP is looping over open_packet() in an infinite
loop. Each time out_pos gets increased a little. Finally, after overwriting
the whole stack, it will SIGSEGV.
===
https://svn.php.net/repository/php/php-src/tags/php_5_3_9RC4/sapi/fpm/fpm/fastcgi.c
===
int fcgi_write(fcgi_request *req, fcgi_request_type type, const char *str,
int len)
{
int limit, rest;
if (len = 0) {
return 0;
}
if (req-out_hdr req-out_hdr-type != type) {
close_packet(req);
}
/* Optimized version */
limit = sizeof(req-out_buf) - (req-out_pos - req-out_buf);
if (!req-out_hdr) {
limit -= sizeof(fcgi_header);
if (limit 0) limit = 0;
}
if (len limit) {
if (!req-out_hdr) {
open_packet(req, type);
}
memcpy(req-out_pos, str, len);
req-out_pos += len;
} else if (len - limit sizeof(req-out_buf) - sizeof(fcgi_header)) {
if (!req-out_hdr) {
a) open_packet(req, type);
}
if (limit 0) {
memcpy(req-out_pos, str, limit);
req-out_pos += limit;
}
if (!fcgi_flush(req, 0)) {
b) return -1;
}
===
https://svn.php.net/repository/php/php-src/tags/php_5_3_9RC4/sapi/fpm/fpm/fpm_main.c
===
static inline size_t sapi_cgibin_single_write(const char *str, uint
str_length TSRMLS_DC)
{
c) size_t ret;
/* sapi has started which means everyhting must be send through fcgi */
if (fpm_is_running) {
fcgi_request *request = (fcgi_request*) SG(server_context);
ret = fcgi_write(request, FCGI_STDOUT, str, str_length);
d) if (ret = 0) {
return 0;
}
return ret;
}
--
Edit bug report at https://bugs.php.net/bug.php?id=60629edit=1
--
Try a snapshot (PHP 5.4):
https://bugs.php.net/fix.php?id=60629r=trysnapshot54
Try a snapshot (PHP 5.3):
https://bugs.php.net/fix.php?id=60629r=trysnapshot53
Try a snapshot (trunk):
https://bugs.php.net/fix.php?id=60629r=trysnapshottrunk
Fixed in SVN:
https://bugs.php.net/fix.php?id=60629r=fixed
Fixed in SVN and need be documented:
https://bugs.php.net/fix.php?id=60629r=needdocs
Fixed in release:
https://bugs.php.net/fix.php?id=60629r=alreadyfixed
Need backtrace:
https://bugs.php.net/fix.php?id=60629r=needtrace
Need Reproduce Script:
https://bugs.php.net/fix.php?id=60629r=needscript
Try newer version:
https://bugs.php.net/fix.php?id=60629r=oldversion
Not developer issue:
https://bugs.php.net/fix.php?id=60629r=support
Expected behavior:
https://bugs.php.net/fix.php?id=60629r=notwrong
Not enough info:
https://bugs.php.net/fix.php?id=60629r=notenoughinfo
Submitted twice:
https://bugs.php.net/fix.php?id=60629r=submittedtwice
register_globals:
https://bugs.php.net/fix.php?id=60629r=globals
PHP 4 support discontinued:
https://bugs.php.net/fix.php?id=60629r=php4
Daylight Savings:https://bugs.php.net/fix.php?id=60629r=dst
IIS Stability:
https://bugs.php.net/fix.php?id=60629r=isapi
Install GNU Sed:
https://bugs.php.net/fix.php?id=60629r=gnused
Floating point limitations:
https://bugs.php.net/fix.php?id=60629r=float
No Zend Extensions:
https://bugs.php.net/fix.php?id=60629r=nozend
MySQL Configuration Error:
https://bugs.php.net/fix.php?id=60629r=mysqlcfg
Bug #60629 [Com]: memory corruption when web server closed the fcgi fd(?)
Edit report at https://bugs.php.net/bug.php?id=60629edit=1
ID: 60629
Comment by: phpbugs at oops dot mooo dot com
Reported by:phpbugs at oops dot mooo dot com
Summary:memory corruption when web server closed the fcgi
fd(?)
Status: Open
Type: Bug
Package:FPM related
Operating System: Debian Squeeze
PHP Version:5.3.9RC4
Block user comment: N
Private report: N
New Comment:
I think it might've been introduced in this commit (~line 270).
http://svn.php.net/viewvc/php/php-src/tags/php_5_3_9RC4/sapi/fpm/fpm/fpm_main.c?r1=317894r2=317897
It looks like write() might have the same problem, since it returns a ssize_t
that's casted to size_t.
Fix might be to use ssize_t instead?
Previous Comments:
[2011-12-30 23:12:00] phpbugs at oops dot mooo dot com
Description:
I tried php5.3.9RC4 today and got a few core dumps.
I think b)fcgi_flush() returns false, making fcgi_write return -1. Then
sapi_cgibin_single_write will make it positive because ret is unsigned in c).
As a result, the comparison in d) will fail.
In debugger it looks like PHP is looping over open_packet() in an infinite
loop. Each time out_pos gets increased a little. Finally, after overwriting the
whole stack, it will SIGSEGV.
===
https://svn.php.net/repository/php/php-src/tags/php_5_3_9RC4/sapi/fpm/fpm/fastcgi.c
===
int fcgi_write(fcgi_request *req, fcgi_request_type type, const char *str, int
len)
{
int limit, rest;
if (len = 0) {
return 0;
}
if (req-out_hdr req-out_hdr-type != type) {
close_packet(req);
}
/* Optimized version */
limit = sizeof(req-out_buf) - (req-out_pos - req-out_buf);
if (!req-out_hdr) {
limit -= sizeof(fcgi_header);
if (limit 0) limit = 0;
}
if (len limit) {
if (!req-out_hdr) {
open_packet(req, type);
}
memcpy(req-out_pos, str, len);
req-out_pos += len;
} else if (len - limit sizeof(req-out_buf) - sizeof(fcgi_header)) {
if (!req-out_hdr) {
a) open_packet(req, type);
}
if (limit 0) {
memcpy(req-out_pos, str, limit);
req-out_pos += limit;
}
if (!fcgi_flush(req, 0)) {
b) return -1;
}
===
https://svn.php.net/repository/php/php-src/tags/php_5_3_9RC4/sapi/fpm/fpm/fpm_main.c
===
static inline size_t sapi_cgibin_single_write(const char *str, uint str_length
TSRMLS_DC)
{
c) size_t ret;
/* sapi has started which means everyhting must be send through fcgi */
if (fpm_is_running) {
fcgi_request *request = (fcgi_request*) SG(server_context);
ret = fcgi_write(request, FCGI_STDOUT, str, str_length);
d) if (ret = 0) {
return 0;
}
return ret;
}
--
Edit this bug report at https://bugs.php.net/bug.php?id=60629edit=1
