#37560 [Com]: MySQLi connection is not cleaned up properly
ID: 37560 Comment by: sroussey at network54 dot com Reported By: tsr2600 at gmail dot com Status: Assigned Bug Type: MySQLi related Operating System: FreeBSD 6.1 PHP Version: 5.1.4 Assigned To: georg New Comment: I should add, that I could not confirm this with Exceptions, only fatal errors. Previous Comments: [2006-05-26 02:08:27] soussey at network54 dot com I can confirm this. It also happens under FastCGI. If a page can be found that produces an error, an attacker can use this repeatedly to shut down an entire site. The attack need only be a person and a browser and need not to continue in order to DOS and bring down a site. [2006-05-23 11:42:53] tsr2600 at gmail dot com Description: When a MySQLi resource is created, a fatal error or exception (possibly others) will result in the script terminating but MySQL's SHOW PROCESSLIST; will report a Reading from net state indefinitely for as many connections as were created before script termination. These connections will be accumulated until MySQL fails with too many connections. This only occurs when PHP is running as an Apache module, it does not occur when PHP is running from the command line. Also, this does not occur with the MySQL PHP functions, only MySQLi. I have tested this on: FreeBSD 6.1, PHP 5.1.4, Apache 2.0.58, MySQL 4.0.19 Gentoo, PHP 5.1.4, Apache 2.2.0, MySQL 4.0.19 Reproduce code: --- ?php $dbh = mysqli_connect($any, $valid, $params, $work); some_undefined_function_resulting_in_error(); ? Expected result: A fatal error, telling me that I made a call to an undefined function. I expect no residual MySQLi connections. Actual result: -- A fatal error, telling me that I made a call to an undefined function. However, I still have a residual MySQLi connection, as reported by MySQL's SHOW PROCESSLIST; -- Edit this bug report at http://bugs.php.net/?id=37560edit=1
#28198 [NEW]: Crash on a POST
From: sroussey at network54 dot com Operating system: RHEL 3 PHP version: 4.3.6 PHP Bug Type: Reproducible crash Bug description: Crash on a POST Description: I could use some help trying to isolate this crashing bug. Seems like it is stuck in a loop. Reproduce code: --- I have PHP compiled with --enable-debug and both it and apache are compiled with '-g' option to CFLAGS. Should I not get a better backtrace? Expected result: no crashes. Sigh. Actual result: -- #1-3540 0x080fff5b in execute () #3541 0x080fff5b in execute () #3542 0x080fff5b in execute () #3543 0x080fff5b in execute () #3544 0x080fff5b in execute () #3545 0x080fff5b in execute () #3546 0x080fff5b in execute () #3547 0x080fff5b in execute () #3548 0x080fff5b in execute () #3549 0x080fff5b in execute () #3550 0x080fff5b in execute () #3551 0x080fff5b in execute () #3552 0x080fff5b in execute () #3553 0x080fff5b in execute () #3554 0x080fff5b in execute () #3555 0x080fff5b in execute () #3556 0x080fff5b in execute () #3557 0x08101ce6 in execute () #3558 0x08101ce6 in execute () #3559 0x080f0426 in zend_execute_scripts () #3560 0x080c721b in php_execute_script () #3561 0x08104909 in apache_php_module_main () #3562 0x080be050 in ssl_expr_yyinput () #3563 0x080be0bb in ssl_expr_yyinput () #3564 0x081e3b84 in ap_invoke_handler () #3565 0x081f8a6b in ap_some_auth_required () #3566 0x081f8ec7 in ap_internal_redirect () #3567 0x0809d9ab in ap_get_server_built () #3568 0x081e3b84 in ap_invoke_handler () #3569 0x081f8a6b in ap_some_auth_required () #3570 0x081f8aca in ap_process_request () #3571 0x081efbdb in ap_child_terminate () #3572 0x081efda2 in ap_child_terminate () #3573 0x081eff09 in ap_child_terminate () #3574 0x081f05a8 in ap_child_terminate () #3575 0x081f0de0 in main () #3576 0x42015967 in __libc_start_main () from /lib/i686/libc.so.6 -- Edit bug report at http://bugs.php.net/?id=28198edit=1 -- Try a CVS snapshot (php4): http://bugs.php.net/fix.php?id=28198r=trysnapshot4 Try a CVS snapshot (php5): http://bugs.php.net/fix.php?id=28198r=trysnapshot5 Fixed in CVS: http://bugs.php.net/fix.php?id=28198r=fixedcvs Fixed in release: http://bugs.php.net/fix.php?id=28198r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=28198r=needtrace Need Reproduce Script: http://bugs.php.net/fix.php?id=28198r=needscript Try newer version: http://bugs.php.net/fix.php?id=28198r=oldversion Not developer issue:http://bugs.php.net/fix.php?id=28198r=support Expected behavior: http://bugs.php.net/fix.php?id=28198r=notwrong Not enough info:http://bugs.php.net/fix.php?id=28198r=notenoughinfo Submitted twice:http://bugs.php.net/fix.php?id=28198r=submittedtwice register_globals: http://bugs.php.net/fix.php?id=28198r=globals PHP 3 support discontinued: http://bugs.php.net/fix.php?id=28198r=php3 Daylight Savings: http://bugs.php.net/fix.php?id=28198r=dst IIS Stability: http://bugs.php.net/fix.php?id=28198r=isapi Install GNU Sed:http://bugs.php.net/fix.php?id=28198r=gnused Floating point limitations: http://bugs.php.net/fix.php?id=28198r=float
#27629 [Fbk-Csd]: crashes with illegal instruction
ID: 27629
User updated by: sroussey at network54 dot com
Reported By: sroussey at network54 dot com
-Status: Feedback
+Status: Closed
Bug Type: Reproducible crash
Operating System: Linux 2.4.20
PHP Version: 4.3.5RC3
New Comment:
Must have been a gcc issue. Restarted machine and unpacked a fresh
tar.gz and it works fine. Soory to waste any time.
Previous Comments:
[2004-03-18 08:45:41] [EMAIL PROTECTED]
Please generate a backtrace with a DEBUG version of PHP
without heavy optimization flags.
[2004-03-17 20:31:39] sroussey at network54 dot com
BTW: I have an strace (from the version that crashes -- that is,
without the debug option)
# tail trace_file -n 50
lstat64(/root/webserver_software_tmp, {st_mode=S_IFDIR|0755,
st_size=4096, ...}) = 0
lstat64(/root/webserver_software_tmp/php-4.3.5RC3,
{st_mode=S_IFDIR|0775, st_size=4096, ...}) = 0
lstat64(/root/webserver_software_tmp/php-4.3.5RC3/pear,
{st_mode=S_IFDIR|0775, st_size=4096, ...}) = 0
lstat64(/root/webserver_software_tmp/php-4.3.5RC3/pear/PEAR,
{st_mode=S_IFDIR|0775, st_size=4096, ...}) = 0
lstat64(/root/webserver_software_tmp/php-4.3.5RC3/pear/PEAR/Registry.php,
{st_mode=S_IFREG|0664, st_size=15079, ...}) = 0
open(/root/webserver_software_tmp/php-4.3.5RC3/pear/PEAR/Registry.php,
O_RDONLY) = 3
fstat64(3, {st_mode=S_IFREG|0664, st_size=15079, ...}) = 0
fstat64(3, {st_mode=S_IFREG|0664, st_size=15079, ...}) = 0
lseek(3, 0, SEEK_CUR) = 0
lseek(3, 0, SEEK_SET) = 0
read(3, ?php\n//\n// +---..., 8192) = 8192
read(3, return $err;\n ..., 8192) = 6887
brk(0) = 0x847e000
brk(0x8482000) = 0x8482000
brk(0) = 0x8482000
brk(0x8485000) = 0x8485000
brk(0) = 0x8485000
brk(0x8487000) = 0x8487000
brk(0) = 0x8487000
brk(0x8488000) = 0x8488000
read(3, , 8192) = 0
close(3)= 0
stat64(/root/webserver_software_tmp/php-4.3.5RC3/pear/System.php,
{st_mode=S_IFREG|0664, st_size=17972, ...}) = 0
getcwd(/root/webserver_software_tmp/php-4.3.5RC3, 4096) = 42
lstat64(/root, {st_mode=S_IFDIR|0750, st_size=4096, ...}) = 0
lstat64(/root/webserver_software_tmp, {st_mode=S_IFDIR|0755,
st_size=4096, ...}) = 0
lstat64(/root/webserver_software_tmp/php-4.3.5RC3,
{st_mode=S_IFDIR|0775, st_size=4096, ...}) = 0
lstat64(/root/webserver_software_tmp/php-4.3.5RC3/pear,
{st_mode=S_IFDIR|0775, st_size=4096, ...}) = 0
lstat64(/root/webserver_software_tmp/php-4.3.5RC3/pear/System.php,
{st_mode=S_IFREG|0664, st_size=17972, ...}) = 0
open(/root/webserver_software_tmp/php-4.3.5RC3/pear/System.php,
O_RDONLY) = 3
fstat64(3, {st_mode=S_IFREG|0664, st_size=17972, ...}) = 0
fstat64(3, {st_mode=S_IFREG|0664, st_size=17972, ...}) = 0
lseek(3, 0, SEEK_CUR) = 0
lseek(3, 0, SEEK_SET) = 0
close(3)= 0
stat64(/root/webserver_software_tmp/php-4.3.5RC3/pear/PEAR.php,
{st_mode=S_IFREG|0664, st_size=29746, ...}) = 0
getcwd(/root/webserver_software_tmp/php-4.3.5RC3, 4096) = 42
lstat64(/root, {st_mode=S_IFDIR|0750, st_size=4096, ...}) = 0
lstat64(/root/webserver_software_tmp, {st_mode=S_IFDIR|0755,
st_size=4096, ...}) = 0
lstat64(/root/webserver_software_tmp/php-4.3.5RC3,
{st_mode=S_IFDIR|0775, st_size=4096, ...}) = 0
lstat64(/root/webserver_software_tmp/php-4.3.5RC3/pear,
{st_mode=S_IFDIR|0775, st_size=4096, ...}) = 0
lstat64(/root/webserver_software_tmp/php-4.3.5RC3/pear/PEAR.php,
{st_mode=S_IFREG|0664, st_size=29746, ...}) = 0
open(/root/webserver_software_tmp/php-4.3.5RC3/pear/PEAR.php,
O_RDONLY) = 3
fstat64(3, {st_mode=S_IFREG|0664, st_size=29746, ...}) = 0
fstat64(3, {st_mode=S_IFREG|0664, st_size=29746, ...}) = 0
lseek(3, 0, SEEK_CUR) = 0
lseek(3, 0, SEEK_SET) = 0
close(3)= 0
--- SIGILL (Illegal instruction) ---
+++ killed by SIGILL +++
[2004-03-17 20:28:35] sroussey at network54 dot com
Well, that was the backtrace before I did a debug version. When I
changed the CFLAGS to add -g as you suggested and added --enable-debug
then it no longer crashes.
[2004-03-17 20:28:27] [EMAIL PROTECTED]
What this backtrace generated with debug build of PHP?
The backtrace should've been more detailed if it was.
[2004-03-17 20:19:21] sroussey at network54 dot com
#27629 [NEW]: crashes with illegal instruction
From: sroussey at network54 dot com Operating system: Linux 2.4.20 PHP version: 4.3.5RC3 PHP Bug Type: Reproducible crash Bug description: crashes with illegal instruction Description: PHP 4.3.5RC3 crashes with illegal instruction Reproduce code: --- CC=gcc CFLAGS=-O3 -march=$CPU CXX=gcc \ ./configure \ --with-mysql=/usr \ --with-gd \ --with-dom \ --with-zlib \ --with-xml \ --with-openssl=/usr/local/ssl \ --with-apache=../apache-1.3.29\ --enable-inline-optimization \ --enable-shmop \ --enable-memory-limit make make install Expected result: noraml installation... Actual result: -- Installing PHP SAPI module: apache Installing PHP CLI binary:/usr/local/bin/ Installing PHP CLI man page: /usr/local/man/man1/ Installing PEAR environment: /usr/local/lib/php/ make[1]: *** [install-pear-installer] Illegal instruction make: *** [install-pear] Error 2 I can confirm that php crashes in the make when the php cli is used in install-pear-installer Same config on php 4.3.4 has no issues. -- Edit bug report at http://bugs.php.net/?id=27629edit=1 -- Try a CVS snapshot (php4): http://bugs.php.net/fix.php?id=27629r=trysnapshot4 Try a CVS snapshot (php5): http://bugs.php.net/fix.php?id=27629r=trysnapshot5 Fixed in CVS: http://bugs.php.net/fix.php?id=27629r=fixedcvs Fixed in release: http://bugs.php.net/fix.php?id=27629r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=27629r=needtrace Need Reproduce Script: http://bugs.php.net/fix.php?id=27629r=needscript Try newer version: http://bugs.php.net/fix.php?id=27629r=oldversion Not developer issue:http://bugs.php.net/fix.php?id=27629r=support Expected behavior: http://bugs.php.net/fix.php?id=27629r=notwrong Not enough info:http://bugs.php.net/fix.php?id=27629r=notenoughinfo Submitted twice:http://bugs.php.net/fix.php?id=27629r=submittedtwice register_globals: http://bugs.php.net/fix.php?id=27629r=globals PHP 3 support discontinued: http://bugs.php.net/fix.php?id=27629r=php3 Daylight Savings: http://bugs.php.net/fix.php?id=27629r=dst IIS Stability: http://bugs.php.net/fix.php?id=27629r=isapi Install GNU Sed:http://bugs.php.net/fix.php?id=27629r=gnused Floating point limitations: http://bugs.php.net/fix.php?id=27629r=float
#27629 [Fbk-Opn]: crashes with illegal instruction
ID: 27629 User updated by: sroussey at network54 dot com Reported By: sroussey at network54 dot com -Status: Feedback +Status: Open Bug Type: Reproducible crash Operating System: Linux 2.4.20 PHP Version: 4.3.5RC3 New Comment: The line in the Makefile gets expanded to this: /root/webserver_software_tmp/php-4.3.5RC3/sapi/cli/php -n -dshort_open_tag=0 -dsafe_mode=0 /root/webserver_software_tmp/php-4.3.5RC3/pear/install-pear.php -d /usr/local/lib/php -b /usr/local/bin /root/webserver_software_tmp/php-4.3.5RC3/pear/package-*.xml gdb on the above has a bt of: Starting program: /root/webserver_software_tmp/php-4.3.5RC3/sapi/cli/php -n -dshort_open_tag=0 -dsafe_mode=0 /root/webserver_software_tmp/php-4.3.5RC3/pear/install-pear.php -d /usr/local/lib/php -b /usr/local/bin /root/webserver_software_tmp/php-4.3.5RC3/pear/package-*.xml Program received signal SIGILL, Illegal instruction. 0x08160493 in sub_function () (gdb) bt #0 0x08160493 in sub_function () #1 0x0816e7f2 in execute () #2 0x081711be in execute () #3 0x081711be in execute () #4 0x08164547 in zend_execute_scripts () #5 0x0813cf2e in php_execute_script () #6 0x08174801 in main () #7 0x42015967 in __libc_start_main () from /lib/i686/libc.so.6 Previous Comments: [2004-03-17 19:49:32] [EMAIL PROTECTED] 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 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. set CFLAGS to -g, add --enable-debug to your configure and if it still crashes generate a backtrace. [2004-03-17 19:45:37] sroussey at network54 dot com Description: PHP 4.3.5RC3 crashes with illegal instruction Reproduce code: --- CC=gcc CFLAGS=-O3 -march=$CPU CXX=gcc \ ./configure \ --with-mysql=/usr \ --with-gd \ --with-dom \ --with-zlib \ --with-xml \ --with-openssl=/usr/local/ssl \ --with-apache=../apache-1.3.29\ --enable-inline-optimization \ --enable-shmop \ --enable-memory-limit make make install Expected result: noraml installation... Actual result: -- Installing PHP SAPI module: apache Installing PHP CLI binary:/usr/local/bin/ Installing PHP CLI man page: /usr/local/man/man1/ Installing PEAR environment: /usr/local/lib/php/ make[1]: *** [install-pear-installer] Illegal instruction make: *** [install-pear] Error 2 I can confirm that php crashes in the make when the php cli is used in install-pear-installer Same config on php 4.3.4 has no issues. -- Edit this bug report at http://bugs.php.net/?id=27629edit=1
#27629 [Fbk-Opn]: crashes with illegal instruction
ID: 27629 User updated by: sroussey at network54 dot com Reported By: sroussey at network54 dot com -Status: Feedback +Status: Open Bug Type: Reproducible crash Operating System: Linux 2.4.20 PHP Version: 4.3.5RC3 New Comment: Well, that was the backtrace before I did a debug version. When I changed the CFLAGS to add -g as you suggested and added --enable-debug then it no longer crashes. Previous Comments: [2004-03-17 20:28:27] [EMAIL PROTECTED] What this backtrace generated with debug build of PHP? The backtrace should've been more detailed if it was. [2004-03-17 20:19:21] sroussey at network54 dot com The line in the Makefile gets expanded to this: /root/webserver_software_tmp/php-4.3.5RC3/sapi/cli/php -n -dshort_open_tag=0 -dsafe_mode=0 /root/webserver_software_tmp/php-4.3.5RC3/pear/install-pear.php -d /usr/local/lib/php -b /usr/local/bin /root/webserver_software_tmp/php-4.3.5RC3/pear/package-*.xml gdb on the above has a bt of: Starting program: /root/webserver_software_tmp/php-4.3.5RC3/sapi/cli/php -n -dshort_open_tag=0 -dsafe_mode=0 /root/webserver_software_tmp/php-4.3.5RC3/pear/install-pear.php -d /usr/local/lib/php -b /usr/local/bin /root/webserver_software_tmp/php-4.3.5RC3/pear/package-*.xml Program received signal SIGILL, Illegal instruction. 0x08160493 in sub_function () (gdb) bt #0 0x08160493 in sub_function () #1 0x0816e7f2 in execute () #2 0x081711be in execute () #3 0x081711be in execute () #4 0x08164547 in zend_execute_scripts () #5 0x0813cf2e in php_execute_script () #6 0x08174801 in main () #7 0x42015967 in __libc_start_main () from /lib/i686/libc.so.6 [2004-03-17 19:49:32] [EMAIL PROTECTED] 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 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. set CFLAGS to -g, add --enable-debug to your configure and if it still crashes generate a backtrace. [2004-03-17 19:45:37] sroussey at network54 dot com Description: PHP 4.3.5RC3 crashes with illegal instruction Reproduce code: --- CC=gcc CFLAGS=-O3 -march=$CPU CXX=gcc \ ./configure \ --with-mysql=/usr \ --with-gd \ --with-dom \ --with-zlib \ --with-xml \ --with-openssl=/usr/local/ssl \ --with-apache=../apache-1.3.29\ --enable-inline-optimization \ --enable-shmop \ --enable-memory-limit make make install Expected result: noraml installation... Actual result: -- Installing PHP SAPI module: apache Installing PHP CLI binary:/usr/local/bin/ Installing PHP CLI man page: /usr/local/man/man1/ Installing PEAR environment: /usr/local/lib/php/ make[1]: *** [install-pear-installer] Illegal instruction make: *** [install-pear] Error 2 I can confirm that php crashes in the make when the php cli is used in install-pear-installer Same config on php 4.3.4 has no issues. -- Edit this bug report at http://bugs.php.net/?id=27629edit=1
#27629 [Opn]: crashes with illegal instruction
ID: 27629
User updated by: sroussey at network54 dot com
Reported By: sroussey at network54 dot com
Status: Open
Bug Type: Reproducible crash
Operating System: Linux 2.4.20
PHP Version: 4.3.5RC3
New Comment:
BTW: I have an strace (from the version that crashes -- that is,
without the debug option)
# tail trace_file -n 50
lstat64(/root/webserver_software_tmp, {st_mode=S_IFDIR|0755,
st_size=4096, ...}) = 0
lstat64(/root/webserver_software_tmp/php-4.3.5RC3,
{st_mode=S_IFDIR|0775, st_size=4096, ...}) = 0
lstat64(/root/webserver_software_tmp/php-4.3.5RC3/pear,
{st_mode=S_IFDIR|0775, st_size=4096, ...}) = 0
lstat64(/root/webserver_software_tmp/php-4.3.5RC3/pear/PEAR,
{st_mode=S_IFDIR|0775, st_size=4096, ...}) = 0
lstat64(/root/webserver_software_tmp/php-4.3.5RC3/pear/PEAR/Registry.php,
{st_mode=S_IFREG|0664, st_size=15079, ...}) = 0
open(/root/webserver_software_tmp/php-4.3.5RC3/pear/PEAR/Registry.php,
O_RDONLY) = 3
fstat64(3, {st_mode=S_IFREG|0664, st_size=15079, ...}) = 0
fstat64(3, {st_mode=S_IFREG|0664, st_size=15079, ...}) = 0
lseek(3, 0, SEEK_CUR) = 0
lseek(3, 0, SEEK_SET) = 0
read(3, ?php\n//\n// +---..., 8192) = 8192
read(3, return $err;\n ..., 8192) = 6887
brk(0) = 0x847e000
brk(0x8482000) = 0x8482000
brk(0) = 0x8482000
brk(0x8485000) = 0x8485000
brk(0) = 0x8485000
brk(0x8487000) = 0x8487000
brk(0) = 0x8487000
brk(0x8488000) = 0x8488000
read(3, , 8192) = 0
close(3)= 0
stat64(/root/webserver_software_tmp/php-4.3.5RC3/pear/System.php,
{st_mode=S_IFREG|0664, st_size=17972, ...}) = 0
getcwd(/root/webserver_software_tmp/php-4.3.5RC3, 4096) = 42
lstat64(/root, {st_mode=S_IFDIR|0750, st_size=4096, ...}) = 0
lstat64(/root/webserver_software_tmp, {st_mode=S_IFDIR|0755,
st_size=4096, ...}) = 0
lstat64(/root/webserver_software_tmp/php-4.3.5RC3,
{st_mode=S_IFDIR|0775, st_size=4096, ...}) = 0
lstat64(/root/webserver_software_tmp/php-4.3.5RC3/pear,
{st_mode=S_IFDIR|0775, st_size=4096, ...}) = 0
lstat64(/root/webserver_software_tmp/php-4.3.5RC3/pear/System.php,
{st_mode=S_IFREG|0664, st_size=17972, ...}) = 0
open(/root/webserver_software_tmp/php-4.3.5RC3/pear/System.php,
O_RDONLY) = 3
fstat64(3, {st_mode=S_IFREG|0664, st_size=17972, ...}) = 0
fstat64(3, {st_mode=S_IFREG|0664, st_size=17972, ...}) = 0
lseek(3, 0, SEEK_CUR) = 0
lseek(3, 0, SEEK_SET) = 0
close(3)= 0
stat64(/root/webserver_software_tmp/php-4.3.5RC3/pear/PEAR.php,
{st_mode=S_IFREG|0664, st_size=29746, ...}) = 0
getcwd(/root/webserver_software_tmp/php-4.3.5RC3, 4096) = 42
lstat64(/root, {st_mode=S_IFDIR|0750, st_size=4096, ...}) = 0
lstat64(/root/webserver_software_tmp, {st_mode=S_IFDIR|0755,
st_size=4096, ...}) = 0
lstat64(/root/webserver_software_tmp/php-4.3.5RC3,
{st_mode=S_IFDIR|0775, st_size=4096, ...}) = 0
lstat64(/root/webserver_software_tmp/php-4.3.5RC3/pear,
{st_mode=S_IFDIR|0775, st_size=4096, ...}) = 0
lstat64(/root/webserver_software_tmp/php-4.3.5RC3/pear/PEAR.php,
{st_mode=S_IFREG|0664, st_size=29746, ...}) = 0
open(/root/webserver_software_tmp/php-4.3.5RC3/pear/PEAR.php,
O_RDONLY) = 3
fstat64(3, {st_mode=S_IFREG|0664, st_size=29746, ...}) = 0
fstat64(3, {st_mode=S_IFREG|0664, st_size=29746, ...}) = 0
lseek(3, 0, SEEK_CUR) = 0
lseek(3, 0, SEEK_SET) = 0
close(3)= 0
--- SIGILL (Illegal instruction) ---
+++ killed by SIGILL +++
Previous Comments:
[2004-03-17 20:28:35] sroussey at network54 dot com
Well, that was the backtrace before I did a debug version. When I
changed the CFLAGS to add -g as you suggested and added --enable-debug
then it no longer crashes.
[2004-03-17 20:28:27] [EMAIL PROTECTED]
What this backtrace generated with debug build of PHP?
The backtrace should've been more detailed if it was.
[2004-03-17 20:19:21] sroussey at network54 dot com
The line in the Makefile gets expanded to this:
/root/webserver_software_tmp/php-4.3.5RC3/sapi/cli/php -n
-dshort_open_tag=0 -dsafe_mode=0
/root/webserver_software_tmp/php-4.3.5RC3/pear/install-pear.php -d
/usr/local/lib/php -b /usr/local/bin
/root/webserver_software_tmp/php-4.3.5RC3/pear/package-*.xml
gdb on the above has a bt of:
Starting program:
/root/webserver_software_tmp/php-4.3.5RC3/sapi/cli/php -n
-dshort_open_tag=0 -dsafe_mode=0
/root/webserver_software_tmp/php
#25385 [NoF-Opn]: Segfault in Apache output compression
ID: 25385
User updated by: sroussey at network54 dot com
Reported By: sroussey at network54 dot com
-Status: No Feedback
+Status: Open
Bug Type: Output Control
Operating System: Linux 2.4.20
PHP Version: 4.3.3
New Comment:
An example is impossible. This is not a 100% deterministic statistical
event. It is 0% without the gzhandler stream. It is a little less than
1% with it. So it occurs thousands of times per hour. (And the Apache
people wonder why php sites dont move over to the threaded Apache 2.0
server
)
At any rate, if I had a repeatable piece of code I would have fixed it
and posted a patch. Sadly I dont. It could be that the user hit the
stop button and the pipe broke and that caused some error somewhere
that eventually crashed at this point. It doesnt look like that, but
you get the idea.
It was very difficult to get the backtrace here, since it only happens
under load on the production servers and we have the
MaxRequestsPerChild set to 200. (If we set it to a bigger number then
the chance of the crash increases until the point of being unusable).
Trying to gdb to running processes that have a short life and having
the bug happen to that one, took a long time to get and repeat for
verification. (In retrospect, I should have written a shell script to
do it. Has anyone already done this?).
So anyhow, from my view, sapi_add_header_ex() should never be calling
efree() since it is passed duplicate value of 1. So why is it crashing
there? What am I missing? I got sort of stuck at this point. :(
Previous Comments:
[2003-09-08 09:34:58] [EMAIL PROTECTED]
No feedback was provided. The bug is being suspended because
we assume that you are no longer experiencing the problem.
If this is not the case and you are able to provide the
information that was requested earlier, please do so and
change the status of the bug back to Open. Thank you.
[2003-09-03 13:53:51] [EMAIL PROTECTED]
You don't need to paste us the code, we know it already.
(providing patches is different)
Please provide a short example script that can be used to reproduce
this bug.
[2003-09-03 13:15:25] sroussey at network54 dot com
Description:
While similar to bug#20551, this has a different backtrace.
Apache 1.3.27 error_log has a long list of segfaults (usually 3-12 a
minute, but not every minute). Disabling output compression (via
ob_start ('ob_gzhandler');) stops the segfaults.
This the backtrace:
#0 0x080a3de8 in _efree ()
#1 0x08093099 in sapi_add_header_ex ()
#2 0x080c2c9e in zif_ob_gzhandler ()
#3 0x080aa49c in call_user_function_ex ()
#4 0x0809c584 in php_end_ob_buffer ()
#5 0x0809c6d8 in php_end_ob_buffers ()
#6 0x0808ec05 in php_request_shutdown ()
#7 0x080c0b7b in apache_php_module_main ()
#8 0x08087d0e in ap_get_server_built ()
#9 0x08087eb1 in ap_get_server_built ()
#10 0x081c73bc in ap_invoke_handler ()
#11 0x081dc36a in ap_some_auth_required ()
#12 0x081929de in tsrm_strtok_r ()
#13 0x081c73bc in ap_invoke_handler ()
#14 0x081dc36a in ap_some_auth_required ()
#15 0x081dc5bb in ap_process_request ()
#16 0x081d3ded in ap_child_terminate ()
#17 0x081d3fe5 in ap_child_terminate ()
#18 0x081d438f in ap_child_terminate ()
#19 0x081d4e05 in ap_child_terminate ()
#20 0x081d51f2 in main ()
#21 0x420158f7 in __libc_start_main () from /lib/i686/libc.so.6
For reference, here is sapi_add_header_ex:
SAPI_API int sapi_add_header_ex(char *header_line, uint
header_line_len, zend_bool duplicate, zend_bool replace TSRMLS_DC)
{
sapi_header_line ctr = {0};
int r;
ctr.line = header_line;
ctr.line_len = header_line_len;
r = sapi_header_op(replace ? SAPI_HEADER_REPLACE :
SAPI_HEADER_ADD,
ctr TSRMLS_CC);
if (!duplicate)
efree(header_line);
return r;
}
In PHP_FUNCTION(ob_gzhandler) these are the relevant lines:
switch (coding) {
case CODING_GZIP:
if (sapi_add_header(Content-Encoding: gzip, sizeof(Content-Encoding:
gzip) - 1, 1) == FAILURE) {
return_original = 1;
}
if (sapi_add_header_ex(Vary: Accept-Encoding, sizeof(Vary:
Accept-Encoding) - 1, 1, 0 TSRMLS_CC)==FAILURE) {
return_original = 1;
}
break;
case CODING_DEFLATE:
if (sapi_add_header(Content-Encoding: deflate,
sizeof(Content-Encoding: deflate) - 1, 1) == FAILURE) {
return_original = 1;
}
if (sapi_add_header_ex(Vary: Accept-Encoding, sizeof(Vary:
Accept-Encoding) - 1, 1, 0 TSRMLS_CC)==FAILURE) {
return_original = 1;
}
break;
From my view, sapi_add_header_ex() should never be calling efree()
since it is passed duplicate value of 1.
So why is it crashing there? What am I missing? How can I make it
stop?
gcc version 3.2
#20551 [NoF-Opn]: Output compression causes segfaults (sapi/apache/mod_php.c)
ID: 20551 User updated by: sroussey at network54 dot com -Summary: Output compression causes segfaults (ob_gzhandler) Reported By: sroussey at network54 dot com -Status: No Feedback +Status: Open Bug Type: Apache related Operating System: RedHat 7.2 PHP Version: 4.3.0 New Comment: FYI: This bug was in the final for 4.3.0. Also in 4.3.1. Now also in 4.3.2. Previous Comments: [2003-03-09 18:45:02] [EMAIL PROTECTED] No feedback was provided. The bug is being suspended because we assume that you are no longer experiencing the problem. If this is not the case and you are able to provide the information that was requested earlier, please do so and change the status of the bug back to Open. Thank you. [2003-02-25 02:36:34] [EMAIL PROTECTED] Please try using this CVS snapshot: http://snaps.php.net/php4-STABLE-latest.tar.gz For Windows: http://snaps.php.net/win32/php4-win32-STABLE-latest.zip There was a fix for a possible crash in sapi_apache_header_handler() so please try the latest snapshot. [2003-02-24 12:29:22] plant at virtualsolution dot net I have see the same problem on PHP4.3.1 Apache 1.3.27 Redhat 7.3: Before the upgrade to PHP 4.3.1 with my 4.2.3, ob_start (ob_gzhandler) work OK. Now there aren't way to compress the output, i try also ini_set(output_handler, ob_gzhandler); or ini_set ( zlib.output_compression, 1); with no result. if i try to return to my old ob_start (ob_gzhandler) .. now php return me this Worning: Warning: (null)() [ref.outcontrol]: output handler 'ob_gzhandler' cannot be used twice in Unknown on line 0 Any idea ?? [2003-02-14 00:57:47] sroussey at network54 dot com Tried php4-STABLE-200302140230 and still it segfaults in the Apache module. Either I patch PHP to check r for null, or I turn off 'ob_gzhandler' to stop the segfaults. [2003-02-13 19:55:22] [EMAIL PROTECTED] No feedback was provided. The bug is being suspended because we assume that you are no longer experiencing the problem. If this is not the case and you are able to provide the information that was requested earlier, please do so and change the status of the bug back to Open. Thank you. 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 http://bugs.php.net/20551 -- Edit this bug report at http://bugs.php.net/?id=20551edit=1
#20551 [Opn-Csd]: Output compression causes segfaults (sapi/apache/mod_php.c)
ID: 20551 User updated by: sroussey at network54 dot com Reported By: sroussey at network54 dot com -Status: Open +Status: Closed Bug Type: Apache related Operating System: RedHat 7.2 PHP Version: 4.3.0 New Comment: Reopened wrong report. Previous Comments: [2003-06-15 12:19:31] sroussey at network54 dot com FYI: This bug was in the final for 4.3.0. Also in 4.3.1. Now also in 4.3.2. [2003-03-09 18:45:02] [EMAIL PROTECTED] No feedback was provided. The bug is being suspended because we assume that you are no longer experiencing the problem. If this is not the case and you are able to provide the information that was requested earlier, please do so and change the status of the bug back to Open. Thank you. [2003-02-25 02:36:34] [EMAIL PROTECTED] Please try using this CVS snapshot: http://snaps.php.net/php4-STABLE-latest.tar.gz For Windows: http://snaps.php.net/win32/php4-win32-STABLE-latest.zip There was a fix for a possible crash in sapi_apache_header_handler() so please try the latest snapshot. [2003-02-24 12:29:22] plant at virtualsolution dot net I have see the same problem on PHP4.3.1 Apache 1.3.27 Redhat 7.3: Before the upgrade to PHP 4.3.1 with my 4.2.3, ob_start (ob_gzhandler) work OK. Now there aren't way to compress the output, i try also ini_set(output_handler, ob_gzhandler); or ini_set ( zlib.output_compression, 1); with no result. if i try to return to my old ob_start (ob_gzhandler) .. now php return me this Worning: Warning: (null)() [ref.outcontrol]: output handler 'ob_gzhandler' cannot be used twice in Unknown on line 0 Any idea ?? [2003-02-14 00:57:47] sroussey at network54 dot com Tried php4-STABLE-200302140230 and still it segfaults in the Apache module. Either I patch PHP to check r for null, or I turn off 'ob_gzhandler' to stop the segfaults. 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 http://bugs.php.net/20551 -- Edit this bug report at http://bugs.php.net/?id=20551edit=1
