#31749 [Opn]: deadlock due to libc mutexes not released when timeout signal is delivered

2005-02-19 Thread phpbug2 at mailinator dot com 
 ID:   31749
 User updated by:  phpbug2 at mailinator dot com
 Reported By:  phpbug2 at mailinator dot com
 Status:   Open
 Bug Type: Scripting Engine problem
 Operating System: Linux 2.4.28, 2.4.21-SMP
 PHP Version:  5.0.3, 4.3.10
 New Comment:

I've created a patch against 5.0.3 to implement my "soft timeout" idea
above. It will try to soft-break execution after the timeout period
elapses and then hard-break after another timeout period.

There seem to be a lot of calls to the zend_set_timeout and
zend_unset_timeout functions that I'm not too sure are helping the
situation. Here's what happens using the CLI PHP and printing whenever
certain functions are hit:

$ sapi/cli/php /www/htdocs/time.php
zend_unset_timeout()
zend_set_timeout (0)
zend_set_timeout (0)
zend_set_timeout (0)
zend_unset_timeout()
zend_set_timeout (5)
Array 2005 2217696508 Jan-01-1998 Jan 01 1998 05:00:00
Array 2005 2217696508 Jan-01-1998 Jan 01 1998 05:00:00
Array 2005 2217696510 Jan-01-1998 Jan 01 1998 05:00:00
Array 2005 2217696512 Jan-01-1998 Jan 01 1998 05:00:00
Array 2005 2217696516 Jan-01-1998 Jan 01 1998 05:00:00
Array 2005 2217696516 Jan-01-1998 Jan 01 1998 05:00:00
zend_soft_timeout()
zend_set_timeout (5)
zend_timeout()
zend_set_timeout (5)

Fatal error: Maximum execution time of 5 seconds exceeded in
/www/htdocs/time.php on line 10
zend_unset_timeout()
zend_set_timeout (30)
zend_unset_timeout()

And the patch to 5.0.3 to implement the "zend_soft_timeout" that "works
for me" in that I'm not getting any more deadlocked Apache children:
http://www.r1hosting.net/zend_timeout.patch


Previous Comments:
----------------

[2005-02-17 16:33:31] phpbug2 at mailinator dot com

Hi,
Unfortunately that snapshot did not fix the problem. The child
processes still deadlock.

#0  0x401c10a4 in __pthread_sigsuspend () from
/lib/i686/libpthread.so.0
#1  0x401c0a58 in __pthread_wait_for_restart_signal () from
/lib/i686/libpthread.so.0
#2  0x401c2600 in __pthread_alt_lock () from /lib/i686/libpthread.so.0
#3  0x401bf2e7 in pthread_mutex_lock () from /lib/i686/libpthread.so.0
#4  0x4027caba in free () from /lib/i686/libc.so.6
#5  0x4043d9b8 in shutdown_scanner () at
Zend/zend_language_scanner.c:2881
#6  0x40450aa5 in zend_deactivate () at
/home/r1ch/php4-STABLE-200502171330/Zend/zend.c:689
#7  0x40427d46 in php_request_shutdown (dummy=0x0) at
/home/r1ch/php4-STABLE-200502171330/main/main.c:997
#8  0x404639c7 in php_handler (r=0x81a9628) at
/home/r1ch/php4-STABLE-200502171330/sapi/apache2handler/sapi_apache2.c:567
#9  0x08089d35 in ap_run_handler (r=0x81a9628) at config.c:152
#10 0x0808a340 in ap_invoke_handler (r=0x81a9628) at config.c:364
#11 0x0806eefa in ap_process_request (r=0x81a9628) at
http_request.c:249
#12 0x0806a38d in ap_process_http_connection (c=0x819f418) at
http_core.c:251
#13 0x08094ec5 in ap_run_process_connection (c=0x819f418) at
connection.c:43
#14 0x08088334 in child_main (child_num_arg=-4) at prefork.c:610
#15 0x08088487 in make_child (s=0x401c8398, slot=0) at prefork.c:704
#16 0x080885a8 in startup_children (number_to_start=5) at
prefork.c:722
#17 0x08088e1a in ap_mpm_run (_pconf=0x80cb818, plog=0x81038f8,
s=0x80d0168) at prefork.c:941
#18 0x0808f36d in main (argc=3, argv=0xb284) at main.c:618

This backtrace is from a separate Apache 2 server (prefork) since I
cannot test a PHP4 on my production server as it may break a number of
PHP5 features I am using. However it still shows that the libc mutexes
are not getting released, this time in the free() call. A few
additional runs also reveal the gmtime() mutex as the earlier reports
show:

(gdb) bt
#0  0x401c10a4 in __pthread_sigsuspend () from
/lib/i686/libpthread.so.0
#1  0x401c0a58 in __pthread_wait_for_restart_signal () from
/lib/i686/libpthread.so.0
#2  0x401c2600 in __pthread_alt_lock () from /lib/i686/libpthread.so.0
#3  0x401bf2e7 in pthread_mutex_lock () from /lib/i686/libpthread.so.0
#4  0x402a0c05 in __tz_convert () from /lib/i686/libc.so.6
#5  0x4029ed5e in gmtime_r () from /lib/i686/libc.so.6
#6  0x40136f47 in explode_time (xt=0xbfffeb70, t=1108654539401728,
offset=0, use_localtime=0) at time.c:91
#7  0x40136f82 in apr_time_exp_tz (result=0xbfffeb70,
input=4619712010928521212, offs=0) at time.c:114
#8  0x40136fd3 in apr_time_exp_gmt (result=0xfffc,
input=4619712010928521212) at time.c:122
#9  0x080947d4 in cached_explode (xt=0xbfffeb70, t=1108654262423791,
cache=0xfffc, use_gmt=1) at util_time.c:117
#10 0x08094891 in ap_explode_recent_gmt (tm=0xfffc,
t=4619712010928521212) at util_time.c:143
#11 0x08094a95 in ap_recent_rfc822_date (date_str=0x81a7018 "",
t=4619712010928521212) at util_time.c:200
#12 0x0806c1a0 in basic_http_header (r=0x81a5618, bb=0x81a6ff8,
protocol=0xfffc )
at http_protocol.c:1248
#13 0x0806ca90 in ap_http_header_filter (f=0x81a6298, b=0x81a6f78) at
http_protocol.c:1642
#1

#31749 [Fbk->Opn]: deadlock due to libc mutexes not released when timeout signal is delivered

2005-02-17 Thread phpbug2 at mailinator dot com 
 ID:   31749
 User updated by:  phpbug2 at mailinator dot com
 Reported By:  phpbug2 at mailinator dot com
-Status:   Feedback
+Status:   Open
 Bug Type: Scripting Engine problem
 Operating System: Linux 2.4.28, 2.4.21-SMP
 PHP Version:  5.0.3, 4.3.10
 New Comment:

Hi,
Unfortunately that snapshot did not fix the problem. The child
processes still deadlock.

#0  0x401c10a4 in __pthread_sigsuspend () from
/lib/i686/libpthread.so.0
#1  0x401c0a58 in __pthread_wait_for_restart_signal () from
/lib/i686/libpthread.so.0
#2  0x401c2600 in __pthread_alt_lock () from /lib/i686/libpthread.so.0
#3  0x401bf2e7 in pthread_mutex_lock () from /lib/i686/libpthread.so.0
#4  0x4027caba in free () from /lib/i686/libc.so.6
#5  0x4043d9b8 in shutdown_scanner () at
Zend/zend_language_scanner.c:2881
#6  0x40450aa5 in zend_deactivate () at
/home/r1ch/php4-STABLE-200502171330/Zend/zend.c:689
#7  0x40427d46 in php_request_shutdown (dummy=0x0) at
/home/r1ch/php4-STABLE-200502171330/main/main.c:997
#8  0x404639c7 in php_handler (r=0x81a9628) at
/home/r1ch/php4-STABLE-200502171330/sapi/apache2handler/sapi_apache2.c:567
#9  0x08089d35 in ap_run_handler (r=0x81a9628) at config.c:152
#10 0x0808a340 in ap_invoke_handler (r=0x81a9628) at config.c:364
#11 0x0806eefa in ap_process_request (r=0x81a9628) at
http_request.c:249
#12 0x0806a38d in ap_process_http_connection (c=0x819f418) at
http_core.c:251
#13 0x08094ec5 in ap_run_process_connection (c=0x819f418) at
connection.c:43
#14 0x08088334 in child_main (child_num_arg=-4) at prefork.c:610
#15 0x08088487 in make_child (s=0x401c8398, slot=0) at prefork.c:704
#16 0x080885a8 in startup_children (number_to_start=5) at
prefork.c:722
#17 0x08088e1a in ap_mpm_run (_pconf=0x80cb818, plog=0x81038f8,
s=0x80d0168) at prefork.c:941
#18 0x0808f36d in main (argc=3, argv=0xb284) at main.c:618

This backtrace is from a separate Apache 2 server (prefork) since I
cannot test a PHP4 on my production server as it may break a number of
PHP5 features I am using. However it still shows that the libc mutexes
are not getting released, this time in the free() call. A few
additional runs also reveal the gmtime() mutex as the earlier reports
show:

(gdb) bt
#0  0x401c10a4 in __pthread_sigsuspend () from
/lib/i686/libpthread.so.0
#1  0x401c0a58 in __pthread_wait_for_restart_signal () from
/lib/i686/libpthread.so.0
#2  0x401c2600 in __pthread_alt_lock () from /lib/i686/libpthread.so.0
#3  0x401bf2e7 in pthread_mutex_lock () from /lib/i686/libpthread.so.0
#4  0x402a0c05 in __tz_convert () from /lib/i686/libc.so.6
#5  0x4029ed5e in gmtime_r () from /lib/i686/libc.so.6
#6  0x40136f47 in explode_time (xt=0xbfffeb70, t=1108654539401728,
offset=0, use_localtime=0) at time.c:91
#7  0x40136f82 in apr_time_exp_tz (result=0xbfffeb70,
input=4619712010928521212, offs=0) at time.c:114
#8  0x40136fd3 in apr_time_exp_gmt (result=0xfffc,
input=4619712010928521212) at time.c:122
#9  0x080947d4 in cached_explode (xt=0xbfffeb70, t=1108654262423791,
cache=0xfffc, use_gmt=1) at util_time.c:117
#10 0x08094891 in ap_explode_recent_gmt (tm=0xfffc,
t=4619712010928521212) at util_time.c:143
#11 0x08094a95 in ap_recent_rfc822_date (date_str=0x81a7018 "",
t=4619712010928521212) at util_time.c:200
#12 0x0806c1a0 in basic_http_header (r=0x81a5618, bb=0x81a6ff8,
protocol=0xfffc )
at http_protocol.c:1248
#13 0x0806ca90 in ap_http_header_filter (f=0x81a6298, b=0x81a6f78) at
http_protocol.c:1642
#14 0x080978b1 in ap_pass_brigade (next=0x401c8398, bb=0x8) at
util_filter.c:512
#15 0x08099fef in ap_content_length_filter (f=0x81a6280, b=0x81a6f78)
at protocol.c:1232
#16 0x080978b1 in ap_pass_brigade (next=0x401c8398, bb=0x8) at
util_filter.c:512
#17 0x0806e6b5 in ap_byterange_filter (f=0x81a6268, bb=0x81a6f78) at
http_protocol.c:3031
#18 0x080978b1 in ap_pass_brigade (next=0x401c8398, bb=0x8) at
util_filter.c:512
#19 0x080978b1 in ap_pass_brigade (next=0x401c8398, bb=0x8) at
util_filter.c:512
#20 0x40463a19 in php_handler (r=0x81a5618) at
/home/r1ch/php4-STABLE-200502171330/sapi/apache2handler/sapi_apache2.c:572
#21 0x08089d35 in ap_run_handler (r=0x81a5618) at config.c:152
#22 0x0808a340 in ap_invoke_handler (r=0x81a5618) at config.c:364
#23 0x0806eefa in ap_process_request (r=0x81a5618) at
http_request.c:249
#24 0x0806a38d in ap_process_http_connection (c=0x819f418) at
http_core.c:251
#25 0x08094ec5 in ap_run_process_connection (c=0x819f418) at
connection.c:43
#26 0x08088334 in child_main (child_num_arg=-4) at prefork.c:610
#27 0x08088487 in make_child (s=0x401c8398, slot=5) at prefork.c:704
#28 0x08088719 in perform_idle_server_maintenance (p=0x80cb818) at
prefork.c:839
#29 0x08088e05 in ap_mpm_run (_pconf=0x0, plog=0x81038f8, s=0x3bc) at
prefork.c:1040
#30 0x0808f36d in main (argc=3, argv=0xb284) at main.c:618

Please let me know if you need any additional information.


Previous Comments:


[2005-02-1

#31749 [Opn]: deadlock due to libc mutexes not released when timeout signal is delivered

2005-02-07 Thread phpbug2 at mailinator dot com 
 ID:   31749
 User updated by:  phpbug2 at mailinator dot com
-Summary:  pthread deadlock if script is interrupted in
   time-related functions
 Reported By:  phpbug2 at mailinator dot com
 Status:   Open
-Bug Type: Scripting Engine problem
+Bug Type: Zend Engine 2 problem
-Operating System: Linux 2.4.28
+Operating System: Linux 2.4.28, 2.4.21-SMP
-PHP Version:  5.0.3
+PHP Version:  5.0.3, 4.3.10
 New Comment:

Reproduced on PHP 4.3.10 with Apache 2 prefork on 2.4.21-4.0.1.ELsmp
#1. Updated summary with clearer description of the problem and I
believe this applies to the Zend Engine rather than the Scripting
Engine.


Previous Comments:


[2005-02-03 12:10:41] phpbug2 at mailinator dot com

I believe this is the buggy code. It is setting a signal handler for
SIGPROF that immediately dumps a timeout error message when the signal
is received. However if the signal is delivered whilst PHP is
processing a libc call to time(), a pthread mutex within libc is not
released, causing a deadlock when Apache tries to call time() for the
output.

A fix would be to have PHP set some flag such as "processing time
exceeded" for the request and to then abort the request at the next
available opporunity from within PHP instead of jumping out and leaving
libc in a potentially unstable or dangerous state. Obviously this
reduces the effectiveness of the maximum execution timeout as a
blocking libc call could cause the timeout to be greatly exceeded, but
I see no other safe way of handling this without leaving libc in a
potentially dangerous state. Perhaps two signals could be used, the
first one to break execution if possible at the next available
opportunity and then the current "hard" break if no response within 15
seconds or something.

ZEND_API void zend_timeout(int dummy)
{
TSRMLS_FETCH();

if (zend_on_timeout) {
zend_on_timeout(EG(timeout_seconds) TSRMLS_CC);
}

zend_error(E_ERROR, "Maximum execution time of %d second%s
exceeded",
  EG(timeout_seconds), EG(timeout_seconds) == 1
? "" : "s");
}

...
t_r.it_value.tv_sec = seconds;
t_r.it_value.tv_usec = t_r.it_interval.tv_sec =
t_r.it_interval.tv_usec = 0;

setitimer(ITIMER_PROF, &t_r, NULL);
signal(SIGPROF, zend_timeout);
sigemptyset(&sigset);
sigaddset(&sigset, SIGPROF);
sigprocmask(SIG_UNBLOCK, &sigset, NULL);
}

--------------------

[2005-01-30 07:10:25] phpbug2 at mailinator dot com

Updated summary with new findings.

--------------------

[2005-01-30 07:01:56] phpbug2 at mailinator dot com

Test case, this almost 100% guarantees a deadlock for me with the
following BT:

(gdb) bt
#0  0x001cf666 in sigsuspend () from /lib/libc.so.6
#1  0x00d0bc28 in __pthread_wait_for_restart_signal () from
/lib/libpthread.so.0
#2  0x00d0def0 in __pthread_alt_lock () from /lib/libpthread.so.0
#3  0x00d0a170 in pthread_mutex_lock () from /lib/libpthread.so.0
#4  0x0023f125 in __tz_convert () from /lib/libc.so.6
#5  0x0023d2a1 in gmtime () from /lib/libc.so.6
#6  0x080801fa in ap_gm_timestr_822 (p=0xfffc, sec=1107064749) at
util.c:153
#7  0x0807b7ac in ap_basic_http_header (r=0x2dd1c0) at
http_protocol.c:1585
#8  0x0807b938 in ap_send_http_header (r=0x819ca44) at
http_protocol.c:1852
#9  0x00a74337 in sapi_apache_send_headers (sapi_headers=0xbb0fd8) at
/root/php5cvs/php-src/sapi/apache/mod_php5.c:217
#10 0x009b9923 in sapi_send_headers () at
/root/php5cvs/php-src/main/SAPI.c:760
#11 0x0096741a in php_header () at
/root/php5cvs/php-src/ext/standard/head.c:54
#12 0x009c0764 in php_ub_body_write (str=0xfffc , str_length=4294967292)
at /root/php5cvs/php-src/main/output.c:707
#13 0x009bfac6 in php_end_ob_buffer (send_buffer=1 '\001', just_flush=0
'\0') at /root/php5cvs/php-src/main/output.c:297
#14 0x009bfd13 in php_end_ob_buffers (send_buffer=252 'ü') at
/root/php5cvs/php-src/main/output.c:336
#15 0x009b3021 in php_request_shutdown (dummy=0x0) at
/root/php5cvs/php-src/main/main.c:1183
#16 0x00a74112 in apache_php_module_main (r=0x819ca44,
display_source_mode=0)
at /root/php5cvs/php-src/sapi/apache/sapi_apache.c:60
#17 0x00a7490a in send_php (r=0x819ca44, display_source_mode=0,
filename=0x0)
at /root/php5cvs/php-src/sapi/apache/mod_php5.c:631
#18 0x00a74bd7 in send_parsed_php (r=0x819ca44) at
/root/php5cvs/php-src/sapi/apache/mod_php5.c:646
#19 0x0806c842 in ap_invoke_handler (r=0x819ca44) at http_config.c:475
#20 0x0807edb3 in process_request_internal (r=0x819ca44) at
http_request.c:1298
#21 0x0807ef27 in ap_process_request (r=0x819ca44) at

[suspicious - maybe spam] #31749 [Opn]: pthread deadlock if script is interrupted in time-related functions

2005-02-03 Thread phpbug2 at mailinator dot com 
 ID:   31749
 User updated by:  phpbug2 at mailinator dot com
 Reported By:  phpbug2 at mailinator dot com
 Status:   Open
 Bug Type: Scripting Engine problem
 Operating System: Linux 2.4.28
 PHP Version:  5.0.3
 New Comment:

I believe this is the buggy code. It is setting a signal handler for
SIGPROF that immediately dumps a timeout error message when the signal
is received. However if the signal is delivered whilst PHP is
processing a libc call to time(), a pthread mutex within libc is not
released, causing a deadlock when Apache tries to call time() for the
output.

A fix would be to have PHP set some flag such as "processing time
exceeded" for the request and to then abort the request at the next
available opporunity from within PHP instead of jumping out and leaving
libc in a potentially unstable or dangerous state. Obviously this
reduces the effectiveness of the maximum execution timeout as a
blocking libc call could cause the timeout to be greatly exceeded, but
I see no other safe way of handling this without leaving libc in a
potentially dangerous state. Perhaps two signals could be used, the
first one to break execution if possible at the next available
opportunity and then the current "hard" break if no response within 15
seconds or something.

ZEND_API void zend_timeout(int dummy)
{
TSRMLS_FETCH();

if (zend_on_timeout) {
zend_on_timeout(EG(timeout_seconds) TSRMLS_CC);
}

zend_error(E_ERROR, "Maximum execution time of %d second%s
exceeded",
  EG(timeout_seconds), EG(timeout_seconds) == 1
? "" : "s");
}

...
t_r.it_value.tv_sec = seconds;
t_r.it_value.tv_usec = t_r.it_interval.tv_sec =
t_r.it_interval.tv_usec = 0;

setitimer(ITIMER_PROF, &t_r, NULL);
signal(SIGPROF, zend_timeout);
sigemptyset(&sigset);
sigaddset(&sigset, SIGPROF);
sigprocmask(SIG_UNBLOCK, &sigset, NULL);
}


Previous Comments:
--------------------

[2005-01-30 07:10:25] phpbug2 at mailinator dot com

Updated summary with new findings.

--------------------

[2005-01-30 07:01:56] phpbug2 at mailinator dot com

Test case, this almost 100% guarantees a deadlock for me with the
following BT:

(gdb) bt
#0  0x001cf666 in sigsuspend () from /lib/libc.so.6
#1  0x00d0bc28 in __pthread_wait_for_restart_signal () from
/lib/libpthread.so.0
#2  0x00d0def0 in __pthread_alt_lock () from /lib/libpthread.so.0
#3  0x00d0a170 in pthread_mutex_lock () from /lib/libpthread.so.0
#4  0x0023f125 in __tz_convert () from /lib/libc.so.6
#5  0x0023d2a1 in gmtime () from /lib/libc.so.6
#6  0x080801fa in ap_gm_timestr_822 (p=0xfffc, sec=1107064749) at
util.c:153
#7  0x0807b7ac in ap_basic_http_header (r=0x2dd1c0) at
http_protocol.c:1585
#8  0x0807b938 in ap_send_http_header (r=0x819ca44) at
http_protocol.c:1852
#9  0x00a74337 in sapi_apache_send_headers (sapi_headers=0xbb0fd8) at
/root/php5cvs/php-src/sapi/apache/mod_php5.c:217
#10 0x009b9923 in sapi_send_headers () at
/root/php5cvs/php-src/main/SAPI.c:760
#11 0x0096741a in php_header () at
/root/php5cvs/php-src/ext/standard/head.c:54
#12 0x009c0764 in php_ub_body_write (str=0xfffc , str_length=4294967292)
at /root/php5cvs/php-src/main/output.c:707
#13 0x009bfac6 in php_end_ob_buffer (send_buffer=1 '\001', just_flush=0
'\0') at /root/php5cvs/php-src/main/output.c:297
#14 0x009bfd13 in php_end_ob_buffers (send_buffer=252 'ü') at
/root/php5cvs/php-src/main/output.c:336
#15 0x009b3021 in php_request_shutdown (dummy=0x0) at
/root/php5cvs/php-src/main/main.c:1183
#16 0x00a74112 in apache_php_module_main (r=0x819ca44,
display_source_mode=0)
at /root/php5cvs/php-src/sapi/apache/sapi_apache.c:60
#17 0x00a7490a in send_php (r=0x819ca44, display_source_mode=0,
filename=0x0)
at /root/php5cvs/php-src/sapi/apache/mod_php5.c:631
#18 0x00a74bd7 in send_parsed_php (r=0x819ca44) at
/root/php5cvs/php-src/sapi/apache/mod_php5.c:646
#19 0x0806c842 in ap_invoke_handler (r=0x819ca44) at http_config.c:475
#20 0x0807edb3 in process_request_internal (r=0x819ca44) at
http_request.c:1298
#21 0x0807ef27 in ap_process_request (r=0x819ca44) at
http_request.c:1314
#22 0x080762d0 in child_main (child_num_arg=-1073743648) at
http_main.c:4786
#23 0x08076644 in make_child (s=0x80a929c, slot=4, now=0) at
http_main.c:4956
#24 0x08076704 in startup_children (number_to_start=8) at
http_main.c:4983
#25 0x08077819 in standalone_main (argc=-4, argv=0x0) at
http_main.c:5315
#26 0x080789a7 in main (argc=1, argv=0xbed4) at http_main.c:5657



--------------------

[2005-01-29 18:55:13] phpbug2 at mailinator dot com

I am using Apache 1.3.33 which isn'

#31749 [Opn]: pthread deadlock if script is interrupted in time-related functions

2005-01-29 Thread phpbug2 at mailinator dot com 
 ID:   31749
 User updated by:  phpbug2 at mailinator dot com
-Summary:  pthread deadlock after script execution finishes
 Reported By:  phpbug2 at mailinator dot com
 Status:   Open
 Bug Type: Scripting Engine problem
 Operating System: Linux 2.4.28
 PHP Version:  5.0.3
 New Comment:

Updated summary with new findings.


Previous Comments:


[2005-01-30 07:01:56] phpbug2 at mailinator dot com

Test case, this almost 100% guarantees a deadlock for me with the
following BT:

(gdb) bt
#0  0x001cf666 in sigsuspend () from /lib/libc.so.6
#1  0x00d0bc28 in __pthread_wait_for_restart_signal () from
/lib/libpthread.so.0
#2  0x00d0def0 in __pthread_alt_lock () from /lib/libpthread.so.0
#3  0x00d0a170 in pthread_mutex_lock () from /lib/libpthread.so.0
#4  0x0023f125 in __tz_convert () from /lib/libc.so.6
#5  0x0023d2a1 in gmtime () from /lib/libc.so.6
#6  0x080801fa in ap_gm_timestr_822 (p=0xfffc, sec=1107064749) at
util.c:153
#7  0x0807b7ac in ap_basic_http_header (r=0x2dd1c0) at
http_protocol.c:1585
#8  0x0807b938 in ap_send_http_header (r=0x819ca44) at
http_protocol.c:1852
#9  0x00a74337 in sapi_apache_send_headers (sapi_headers=0xbb0fd8) at
/root/php5cvs/php-src/sapi/apache/mod_php5.c:217
#10 0x009b9923 in sapi_send_headers () at
/root/php5cvs/php-src/main/SAPI.c:760
#11 0x0096741a in php_header () at
/root/php5cvs/php-src/ext/standard/head.c:54
#12 0x009c0764 in php_ub_body_write (str=0xfffc , str_length=4294967292)
at /root/php5cvs/php-src/main/output.c:707
#13 0x009bfac6 in php_end_ob_buffer (send_buffer=1 '\001', just_flush=0
'\0') at /root/php5cvs/php-src/main/output.c:297
#14 0x009bfd13 in php_end_ob_buffers (send_buffer=252 'ü') at
/root/php5cvs/php-src/main/output.c:336
#15 0x009b3021 in php_request_shutdown (dummy=0x0) at
/root/php5cvs/php-src/main/main.c:1183
#16 0x00a74112 in apache_php_module_main (r=0x819ca44,
display_source_mode=0)
at /root/php5cvs/php-src/sapi/apache/sapi_apache.c:60
#17 0x00a7490a in send_php (r=0x819ca44, display_source_mode=0,
filename=0x0)
at /root/php5cvs/php-src/sapi/apache/mod_php5.c:631
#18 0x00a74bd7 in send_parsed_php (r=0x819ca44) at
/root/php5cvs/php-src/sapi/apache/mod_php5.c:646
#19 0x0806c842 in ap_invoke_handler (r=0x819ca44) at http_config.c:475
#20 0x0807edb3 in process_request_internal (r=0x819ca44) at
http_request.c:1298
#21 0x0807ef27 in ap_process_request (r=0x819ca44) at
http_request.c:1314
#22 0x080762d0 in child_main (child_num_arg=-1073743648) at
http_main.c:4786
#23 0x08076644 in make_child (s=0x80a929c, slot=4, now=0) at
http_main.c:4956
#24 0x08076704 in startup_children (number_to_start=8) at
http_main.c:4983
#25 0x08077819 in standalone_main (argc=-4, argv=0x0) at
http_main.c:5315
#26 0x080789a7 in main (argc=1, argv=0xbed4) at http_main.c:5657



----

[2005-01-29 18:55:13] phpbug2 at mailinator dot com

I am using Apache 1.3.33 which isn't threaded to my knowledge.

# ./httpd -V
Server version: Apache/1.3.33 (Unix)
Server built:   Nov 11 2004 07:16:41
Server's Module Magic Number: 19990320:16
Server compiled with
 -D HAVE_MMAP
 -D HAVE_SHMGET
 -D USE_SHMGET_SCOREBOARD
 -D USE_MMAP_FILES
 -D HAVE_FCNTL_SERIALIZED_ACCEPT
 -D HAVE_SYSVSEM_SERIALIZED_ACCEPT
 -D SINGLE_LISTEN_UNSERIALIZED_ACCEPT
 -D DYNAMIC_MODULE_LIMIT=64
 -D HARD_SERVER_LIMIT=256
 -D HTTPD_ROOT="/www"
 -D SUEXEC_BIN="/www/bin/suexec"
 -D DEFAULT_PIDLOG="logs/httpd.pid"
 -D DEFAULT_SCOREBOARD="logs/httpd.scoreboard"
 -D DEFAULT_LOCKFILE="logs/httpd.lock"
 -D DEFAULT_ERRORLOG="logs/error_log"
 -D TYPES_CONFIG_FILE="conf/mime.types"
 -D SERVER_CONFIG_FILE="conf/httpd.conf"
 -D ACCESS_CONFIG_FILE="conf/access.conf"
 -D RESOURCE_CONFIG_FILE="conf/srm.conf"

# ./httpd -l
Compiled-in modules:
  http_core.c
  mod_env.c
  mod_log_config.c
  mod_mime.c
  mod_negotiation.c
  mod_status.c
  mod_include.c
  mod_autoindex.c
  mod_dir.c
  mod_cgi.c
  mod_imap.c
  mod_actions.c
  mod_alias.c
  mod_rewrite.c
  mod_access.c
  mod_auth.c
  mod_so.c
  mod_setenvif.c
suexec: enabled; valid wrapper /www/bin/suexec

I am also using the latest versions of mod_security, mod_dav and
mod_throttle. Using non-tls glibc 2.3.2.

Following additional testing it appears the script output DOES NOT get
sent to the client. No data is transferred and eventually the browser
gives a 'Request timed out' message or similar.

I have rebuilt using PHP 5 CVS with -g. Here is the new backtrace after
a child froze:

(gdb) bt
#0  0x001cf666 in sigsuspend () from /lib/libc.so.6
#1  0x00d0bc28 in __pthread_wait_for_restart_signal () from
/lib/libpthread.so.0
#2  0x00d0def0 in __pthread_alt_lock () from /lib/libpthread.so.0
#3  0x00d0a170 in pthread_mutex_lock () from /lib/lib

#31749 [Opn]: pthread deadlock after script execution finishes

2005-01-29 Thread phpbug2 at mailinator dot com 
 ID:   31749
 User updated by:  phpbug2 at mailinator dot com
 Reported By:  phpbug2 at mailinator dot com
 Status:   Open
 Bug Type: Scripting Engine problem
 Operating System: Linux 2.4.28
 PHP Version:  5.0.3
 New Comment:

Test case, this almost 100% guarantees a deadlock for me with the
following BT:

(gdb) bt
#0  0x001cf666 in sigsuspend () from /lib/libc.so.6
#1  0x00d0bc28 in __pthread_wait_for_restart_signal () from
/lib/libpthread.so.0
#2  0x00d0def0 in __pthread_alt_lock () from /lib/libpthread.so.0
#3  0x00d0a170 in pthread_mutex_lock () from /lib/libpthread.so.0
#4  0x0023f125 in __tz_convert () from /lib/libc.so.6
#5  0x0023d2a1 in gmtime () from /lib/libc.so.6
#6  0x080801fa in ap_gm_timestr_822 (p=0xfffc, sec=1107064749) at
util.c:153
#7  0x0807b7ac in ap_basic_http_header (r=0x2dd1c0) at
http_protocol.c:1585
#8  0x0807b938 in ap_send_http_header (r=0x819ca44) at
http_protocol.c:1852
#9  0x00a74337 in sapi_apache_send_headers (sapi_headers=0xbb0fd8) at
/root/php5cvs/php-src/sapi/apache/mod_php5.c:217
#10 0x009b9923 in sapi_send_headers () at
/root/php5cvs/php-src/main/SAPI.c:760
#11 0x0096741a in php_header () at
/root/php5cvs/php-src/ext/standard/head.c:54
#12 0x009c0764 in php_ub_body_write (str=0xfffc , str_length=4294967292)
at /root/php5cvs/php-src/main/output.c:707
#13 0x009bfac6 in php_end_ob_buffer (send_buffer=1 '\001', just_flush=0
'\0') at /root/php5cvs/php-src/main/output.c:297
#14 0x009bfd13 in php_end_ob_buffers (send_buffer=252 'ü') at
/root/php5cvs/php-src/main/output.c:336
#15 0x009b3021 in php_request_shutdown (dummy=0x0) at
/root/php5cvs/php-src/main/main.c:1183
#16 0x00a74112 in apache_php_module_main (r=0x819ca44,
display_source_mode=0)
at /root/php5cvs/php-src/sapi/apache/sapi_apache.c:60
#17 0x00a7490a in send_php (r=0x819ca44, display_source_mode=0,
filename=0x0)
at /root/php5cvs/php-src/sapi/apache/mod_php5.c:631
#18 0x00a74bd7 in send_parsed_php (r=0x819ca44) at
/root/php5cvs/php-src/sapi/apache/mod_php5.c:646
#19 0x0806c842 in ap_invoke_handler (r=0x819ca44) at http_config.c:475
#20 0x0807edb3 in process_request_internal (r=0x819ca44) at
http_request.c:1298
#21 0x0807ef27 in ap_process_request (r=0x819ca44) at
http_request.c:1314
#22 0x080762d0 in child_main (child_num_arg=-1073743648) at
http_main.c:4786
#23 0x08076644 in make_child (s=0x80a929c, slot=4, now=0) at
http_main.c:4956
#24 0x08076704 in startup_children (number_to_start=8) at
http_main.c:4983
#25 0x08077819 in standalone_main (argc=-4, argv=0x0) at
http_main.c:5315
#26 0x080789a7 in main (argc=1, argv=0xbed4) at http_main.c:5657




Previous Comments:
----

[2005-01-29 18:55:13] phpbug2 at mailinator dot com

I am using Apache 1.3.33 which isn't threaded to my knowledge.

# ./httpd -V
Server version: Apache/1.3.33 (Unix)
Server built:   Nov 11 2004 07:16:41
Server's Module Magic Number: 19990320:16
Server compiled with
 -D HAVE_MMAP
 -D HAVE_SHMGET
 -D USE_SHMGET_SCOREBOARD
 -D USE_MMAP_FILES
 -D HAVE_FCNTL_SERIALIZED_ACCEPT
 -D HAVE_SYSVSEM_SERIALIZED_ACCEPT
 -D SINGLE_LISTEN_UNSERIALIZED_ACCEPT
 -D DYNAMIC_MODULE_LIMIT=64
 -D HARD_SERVER_LIMIT=256
 -D HTTPD_ROOT="/www"
 -D SUEXEC_BIN="/www/bin/suexec"
 -D DEFAULT_PIDLOG="logs/httpd.pid"
 -D DEFAULT_SCOREBOARD="logs/httpd.scoreboard"
 -D DEFAULT_LOCKFILE="logs/httpd.lock"
 -D DEFAULT_ERRORLOG="logs/error_log"
 -D TYPES_CONFIG_FILE="conf/mime.types"
 -D SERVER_CONFIG_FILE="conf/httpd.conf"
 -D ACCESS_CONFIG_FILE="conf/access.conf"
 -D RESOURCE_CONFIG_FILE="conf/srm.conf"

# ./httpd -l
Compiled-in modules:
  http_core.c
  mod_env.c
  mod_log_config.c
  mod_mime.c
  mod_negotiation.c
  mod_status.c
  mod_include.c
  mod_autoindex.c
  mod_dir.c
  mod_cgi.c
  mod_imap.c
  mod_actions.c
  mod_alias.c
  mod_rewrite.c
  mod_access.c
  mod_auth.c
  mod_so.c
  mod_setenvif.c
suexec: enabled; valid wrapper /www/bin/suexec

I am also using the latest versions of mod_security, mod_dav and
mod_throttle. Using non-tls glibc 2.3.2.

Following additional testing it appears the script output DOES NOT get
sent to the client. No data is transferred and eventually the browser
gives a 'Request timed out' message or similar.

I have rebuilt using PHP 5 CVS with -g. Here is the new backtrace after
a child froze:

(gdb) bt
#0  0x001cf666 in sigsuspend () from /lib/libc.so.6
#1  0x00d0bc28 in __pthread_wait_for_restart_signal () from
/lib/libpthread.so.0
#2  0x00d0def0 in __pthread_alt_lock () from /lib/libpthread.so.0
#3  0x00d0a170 in pthread_mutex_lock () from /lib/libpthread.so.0
#4  0x0023f125 in __tz_convert () from /lib/libc.so.6
#5  0x0023d2a1 in gmtime () from /lib/libc.so.6
#6  0x08086ce0 in ap_gm_timestr_822 ()

Since this is a calendar module I guess there may be a lot of libc
calls to

#31749 [Fbk->Opn]: pthread deadlock after script execution finishes

2005-01-29 Thread phpbug2 at mailinator dot com 
 ID:   31749
 User updated by:  phpbug2 at mailinator dot com
 Reported By:  phpbug2 at mailinator dot com
-Status:   Feedback
+Status:   Open
 Bug Type: Scripting Engine problem
 Operating System: Linux 2.4.28
 PHP Version:  5.0.3
 New Comment:

I am using Apache 1.3.33 which isn't threaded to my knowledge.

# ./httpd -V
Server version: Apache/1.3.33 (Unix)
Server built:   Nov 11 2004 07:16:41
Server's Module Magic Number: 19990320:16
Server compiled with
 -D HAVE_MMAP
 -D HAVE_SHMGET
 -D USE_SHMGET_SCOREBOARD
 -D USE_MMAP_FILES
 -D HAVE_FCNTL_SERIALIZED_ACCEPT
 -D HAVE_SYSVSEM_SERIALIZED_ACCEPT
 -D SINGLE_LISTEN_UNSERIALIZED_ACCEPT
 -D DYNAMIC_MODULE_LIMIT=64
 -D HARD_SERVER_LIMIT=256
 -D HTTPD_ROOT="/www"
 -D SUEXEC_BIN="/www/bin/suexec"
 -D DEFAULT_PIDLOG="logs/httpd.pid"
 -D DEFAULT_SCOREBOARD="logs/httpd.scoreboard"
 -D DEFAULT_LOCKFILE="logs/httpd.lock"
 -D DEFAULT_ERRORLOG="logs/error_log"
 -D TYPES_CONFIG_FILE="conf/mime.types"
 -D SERVER_CONFIG_FILE="conf/httpd.conf"
 -D ACCESS_CONFIG_FILE="conf/access.conf"
 -D RESOURCE_CONFIG_FILE="conf/srm.conf"

# ./httpd -l
Compiled-in modules:
  http_core.c
  mod_env.c
  mod_log_config.c
  mod_mime.c
  mod_negotiation.c
  mod_status.c
  mod_include.c
  mod_autoindex.c
  mod_dir.c
  mod_cgi.c
  mod_imap.c
  mod_actions.c
  mod_alias.c
  mod_rewrite.c
  mod_access.c
  mod_auth.c
  mod_so.c
  mod_setenvif.c
suexec: enabled; valid wrapper /www/bin/suexec

I am also using the latest versions of mod_security, mod_dav and
mod_throttle. Using non-tls glibc 2.3.2.

Following additional testing it appears the script output DOES NOT get
sent to the client. No data is transferred and eventually the browser
gives a 'Request timed out' message or similar.

I have rebuilt using PHP 5 CVS with -g. Here is the new backtrace after
a child froze:

(gdb) bt
#0  0x001cf666 in sigsuspend () from /lib/libc.so.6
#1  0x00d0bc28 in __pthread_wait_for_restart_signal () from
/lib/libpthread.so.0
#2  0x00d0def0 in __pthread_alt_lock () from /lib/libpthread.so.0
#3  0x00d0a170 in pthread_mutex_lock () from /lib/libpthread.so.0
#4  0x0023f125 in __tz_convert () from /lib/libc.so.6
#5  0x0023d2a1 in gmtime () from /lib/libc.so.6
#6  0x08086ce0 in ap_gm_timestr_822 ()

Since this is a calendar module I guess there may be a lot of libc
calls to time related functions which may explain why gmtime is
deadlocking.

A subsequent request froze in PHP flock() on the session file, which to
me would indicate that the first request is still in processing
somewhere by PHP, even though the backtrace seems to indicate
elsewhere.

(gdb) bt
#0  0x0027cca1 in flock () from /lib/libc.so.6
#1  0x008f365c in ps_files_open (data=0x8b86044, key=0x8bfd0dc
"155e331d3c7ad7493906808d89dae388")
at /root/php5cvs/php-src/ext/session/mod_files.c:166
#2  0x008f3900 in ps_read_files (mod_data=0xfe00, key=0x8bfd0fc "",
val=0xbfffb770, vallen=0xfe00)
at /root/php5cvs/php-src/ext/session/mod_files.c:322
#3  0x008f1029 in php_session_start () at
/root/php5cvs/php-src/ext/session/session.c:746
#4  0x008f2999 in zif_session_start (ht=1, return_value=0x82d8c6c,
this_ptr=0x0, return_value_used=0)
at /root/php5cvs/php-src/ext/session/session.c:1660
#5  0x00a0bf25 in zend_do_fcall_common_helper_SPEC
(execute_data=0xbfffbfa0) at zend_vm_execute.h:175
#6  0x00a10245 in ZEND_DO_FCALL_SPEC_CONST_HANDLER
(execute_data=0xbfffbfa0) at zend_vm_execute.h:1534
#7  0x00a0b96f in execute (op_array=0x82dcde4) at zend_vm_execute.h:78
#8  0x00a0bb86 in zend_do_fcall_common_helper_SPEC
(execute_data=0xbfffd0a0) at zend_vm_execute.h:204
#9  0x00a0b96f in execute (op_array=0x82c65ec) at zend_vm_execute.h:78
#10 0x009ebc14 in zend_execute_scripts (type=8, retval=0x0,
file_count=3) at /root/php5cvs/php-src/Zend/zend.c:1058
#11 0x009b3b38 in php_execute_script (primary_file=0xb400) at
/root/php5cvs/php-src/main/main.c:1636
#12 0x00a7404f in apache_php_module_main (r=0x81ac084,
display_source_mode=0)
at /root/php5cvs/php-src/sapi/apache/sapi_apache.c:54
#13 0x00a7490a in send_php (r=0x81ac084, display_source_mode=0,
filename=0x0)
at /root/php5cvs/php-src/sapi/apache/mod_php5.c:631
#14 0x00a74bd7 in send_parsed_php (r=0x81ac084) at
/root/php5cvs/php-src/sapi/apache/mod_php5.c:646
#15 0x080701e7 in ap_invoke_handler ()
#16 0x00b17016 in zend_vm_decode.0 () from /www/libexec/libphp5.so
#17 0x0017 in ?? ()
#18 0x001b in ?? ()

Restarting Apache and then accessing the same URL results in the page
loading. After using a few more calendar functions in phpWebSite, I
encounted these errors after 30 seconds of 100% CPU usage (looks like a
few PEAR scripts ship with phpWebSite):

Fatal error: Maximum execution time of 30 seconds exceeded in
/home//public_html/test/lib/pear/Date/Calc.php on line 1236

1236:
return(Date_Calc::dateForma

#31749 [NEW]: pthread deadlock after script execution finishes

2005-01-28 Thread phpbug2 at mailinator dot com 
From: phpbug2 at mailinator dot com
Operating system: Linux 2.4.28
PHP version:  5.0.3
PHP Bug Type: Scripting Engine problem
Bug description:  pthread deadlock after script execution finishes

Description:

A certain script (phpWebSite) a client of mine is running causes the
Apache child to deadlock after processing is complete. The output is sent
to the client however so to a normal visitor it appears to be working
fine, but on the server a child deadlocks with every hit to the script.

Srv PID Acc M   CPU SS  Req ConnChild   Slot
Client  VHost   Request
26-024911   1/75/75 W   1.2915390   0   0.3 0.730.73
66.249.xxx.xxx  .xxxGET
/index.php?module=calendar&calendar%5Bview%5D=month&mo

The request sticks in the "W"riting state until Apache is hupped at which
point it moves to "G"racefully finishing and will remain in that state
indefinitely. Closing Apache results in a "Child  did not cleanly
exit, sending SIGKILL" message in the error_log. No errors are logged
prior to the child deadlocking. The hit that causes the deadlock does NOT
get logged to the Apache access_log.

php.ini is pretty much the stock 5.0.3-recommended. No 3rd party modules
such as Zend or Turck are present. Configure string:

'./configure' '--with-imap=/usr' '--with-expat-dir=/usr'
'--enable-sockets' '--with-zlib-dir=/usr' '--with-mysql=/usr'
'--with-mysql-sock=/var/lib/mysql/mysql.sock' '--with-mcrypt=/usr'
'--with-jpeg-dir=/usr' '--with-png-dir=/usr' '--with-freetype-dir=/usr'
'--with-gettext=/usr' '--enable-dba' '--with-db4=/usr' '--with-gdbm=/usr'
'--with-curl=/usr' '--enable-exif' '--with-ttf=/usr'
'--with-apxs=/www/bin/apxs' '--disable-cgi' '--disable-ipv6'
'--enable-gd-native-ttf' '--enable-calendar' '--with-zlib=/usr'
'--with-gd' '--with-gettext' '--disable-posix'
'--with-pgsql=/usr/local/pgsql' '--enable-memory-limit'
'--with-pspell=/usr' '--with-mysqli' '--with-mm' '--with-xsl'

None of the binaries are built with -g which I am afraid seems to limit
the debugging output. -fomit-frame-pointer however is NOT used. Please
inform if this is a problem and I will rebuild.

Reproduce code:
---
phpWebSite
http://phpwebsite.appstate.edu/

The "calendar" module seems to be the one that causes it, however I am
unsure as to whether any events need to be added in certain places etc as
the calendar is not maintained by myself.

I believe the phpWebSite script needed a few minor changes in order to
conform to the new OO model in PHP5. If you require an exact copy of the
installed version and/or data please let me know and I will ask my client.

Expected result:

Not to deadlock.

Actual result:
--
#0  0x001cf666 in sigsuspend () from /lib/libc.so.6
#1  0x00c50c28 in __pthread_wait_for_restart_signal () from
/lib/libpthread.so.0
#2  0x00c52ef0 in __pthread_alt_lock () from /lib/libpthread.so.0
#3  0x00c4f170 in pthread_mutex_lock () from /lib/libpthread.so.0
#4  0x00219fda in free () from /lib/libc.so.6
#5  0x008844f9 in php_error_cb () from /www/libexec/libphp5.so
#6  0x008c2724 in zend_error () from /www/libexec/libphp5.so
#7  0x008b8476 in zend_timeout () from /www/libexec/libphp5.so
#8  0x00c54d0d in __pthread_sighandler () from /lib/libpthread.so.0
#9  
#10 0x00c530f1 in __pthread_alt_unlock () from /lib/libpthread.so.0
#11 0x00c4f42e in pthread_mutex_unlock () from /lib/libpthread.so.0
#12 0x00219fd3 in free () from /lib/libc.so.6
#13 0x0023fcbd in __tzfile_read () from /lib/libc.so.6
#14 0x0023e3ac in tzset_internal () from /lib/libc.so.6
#15 0x0023ef08 in tzset () from /lib/libc.so.6
#16 0x0081b65f in php_putenv_destructor () from /www/libexec/libphp5.so
#17 0x008c93b4 in zend_hash_del_key_or_index () from
/www/libexec/libphp5.so
#18 0x0081c828 in zif_putenv () from /www/libexec/libphp5.so
#19 0x008f951c in zend_do_fcall_common_helper () from
/www/libexec/libphp5.so
#20 0x008f9851 in zend_do_fcall_handler () from /www/libexec/libphp5.so
#21 0x008e76ec in execute () from /www/libexec/libphp5.so
#22 0x008f8fe3 in zend_do_fcall_common_helper () from
/www/libexec/libphp5.so
#23 0x008f972f in zend_do_fcall_by_name_handler () from
/www/libexec/libphp5.so
#24 0x008e76ec in execute () from /www/libexec/libphp5.so
#25 0x008f8fe3 in zend_do_fcall_common_helper () from
/www/libexec/libphp5.so
#26 0x008f972f in zend_do_fcall_by_name_handler () from
/www/libexec/libphp5.so
#27 0x008e76ec in execute () from /www/libexec/libphp5.so
#28 0x008f8fe3 in zend_do_fcall_common_helper () from
/www/libexec/libp