ID: 16994
Updated by: [EMAIL PROTECTED]
Reported By: [EMAIL PROTECTED]
Status: Open
Bug Type: Scripting Engine problem
Operating System: FreeBSD 4.5
PHP Version: 4.2.0
New Comment:
I'm too experiencing an extremely similar problem on two entirely
different FreeBSD machines (hardware-wise), both running
FreeBSD-4.5-RELEASE-p4. apache dies with signal 11, sometimes signal
10, like this:
May 9 13:32:10 freebsd /kernel: pid 1534 (httpd), uid 80: exited on
signal 11
May 9 13:32:11 freebsd /kernel: pid 165 (httpd), uid 80: exited on
signal 11
May 9 13:32:11 freebsd /kernel: pid 164 (httpd), uid 80: exited on
signal 11
May 9 13:32:11 freebsd /kernel: pid 163 (httpd), uid 80: exited on
signal 11
May 9 13:32:11 freebsd /kernel: pid 162 (httpd), uid 80: exited on
signal 11
May 9 13:32:11 freebsd /kernel: pid 161 (httpd), uid 80: exited on
signal 11
May 9 13:32:11 freebsd /kernel: pid 4330 (httpd), uid 80: exited on
signal 11
May 9 13:32:13 freebsd /kernel: pid 157 (httpd), uid 0: exited on
signal 10 (core dumped)
Although I've seen it with different scripts, it was most obvious with
a simple HTTP file upload handling script - almost every time I tried a
file upload (no matter how big), it crashed. I've tried recompiling PHP
without anything but the standard modules (zlib / mysql) - same thing
still. I also tried recompiling apache 1.3.24/php 4.2.0 "by hand"
without DSO (I usually use the FreeBSD port which uses DSOs) and no
optimizations. No luck, same problem. So... I rebuilt both apache and
php using the FreeBSD ports system and with just the default options
(however with --march=pentiumpro!), but added --enable-debug to the PHP
./configure call. After recompiling/installing I called httpd -X as
indicated in the manual, first tried a script which only calls
phpinfo() (this one worked, as always), then tried the file upload
script and was rewarded with a core dump (this time signal 4??) Here's
what I managed to get out of it:
---
s1# gdb /usr/local/sbin/httpd /usr/local/httpd.core
GNU gdb 4.18
Copyright 1998 Free Software Foundation, Inc.
GDB is free software, covered by the GNU General Public License, and
you are
welcome to change it and/or distribute copies of it under certain
conditions.
Type "show copying" to see the conditions.
There is absolutely no warranty for GDB. Type "show warranty" for
details.
This GDB was configured as "i386-unknown-freebsd"...(no debugging
symbols found)...
Core was generated by `httpd'.
Program terminated with signal 4, Illegal instruction.
Reading symbols from /usr/lib/libcrypt.so.2...(no debugging symbols
found)...done.
Reading symbols from /usr/lib/libc.so.4...(no debugging symbols
found)...done.
Reading symbols from /usr/local/libexec/apache/mod_mmap_static.so...(no
debugging symbols found)...done.
Reading symbols from /usr/local/libexec/apache/mod_vhost_alias.so...(no
debugging symbols found)...done.
Reading symbols from /usr/local/libexec/apache/mod_env.so...(no
debugging symbols found)...done.
Reading symbols from /usr/local/libexec/apache/mod_log_config.so...(no
debugging symbols found)...done.
Reading symbols from /usr/local/libexec/apache/mod_mime_magic.so...(no
debugging symbols found)...done.
Reading symbols from /usr/local/libexec/apache/mod_mime.so...(no
debugging symbols found)...done.
Reading symbols from /usr/local/libexec/apache/mod_negotiation.so...(no
debugging symbols found)...done.
Reading symbols from /usr/local/libexec/apache/mod_status.so...(no
debugging symbols found)...done.
Reading symbols from /usr/local/libexec/apache/mod_info.so...(no
debugging symbols found)...done.
Reading symbols from /usr/local/libexec/apache/mod_include.so...(no
debugging symbols found)...done.
Reading symbols from /usr/local/libexec/apache/mod_autoindex.so...(no
debugging symbols found)...done.
Reading symbols from /usr/local/libexec/apache/mod_dir.so...(no
debugging symbols found)...done.
Reading symbols from /usr/local/libexec/apache/mod_cgi.so...(no
debugging symbols found)...done.
Reading symbols from /usr/local/libexec/apache/mod_asis.so...(no
debugging symbols found)...done.
Reading symbols from /usr/local/libexec/apache/mod_imap.so...(no
debugging symbols found)...done.
Reading symbols from /usr/local/libexec/apache/mod_actions.so...(no
debugging symbols found)...done.
Reading symbols from /usr/local/libexec/apache/mod_speling.so...(no
debugging symbols found)...done.
Reading symbols from /usr/local/libexec/apache/mod_userdir.so...(no
debugging symbols found)...done.
Reading symbols from /usr/local/libexec/apache/mod_alias.so...(no
debugging symbols found)...done.
Reading symbols from /usr/local/libexec/apache/mod_rewrite.so...(no
debugging symbols found)...done.
Reading symbols from /usr/local/libexec/apache/mod_access.so...(no
debugging symbols found)...done.
Reading symbols from /usr/local/libexec/apache/mod_auth.so...(no
debugging symbols found)...done.
Reading symbols from /usr/local/libexec/apache/mod_auth_anon.so...(no
debugging symbols found)...done.
Reading symbols from /usr/local/libexec/apache/mod_auth_db.so...(no
debugging symbols found)...done.
Reading symbols from /usr/local/libexec/apache/mod_digest.so...(no
debugging symbols found)...done.
Reading symbols from /usr/local/libexec/apache/libproxy.so...(no
debugging symbols found)...done.
Reading symbols from /usr/local/libexec/apache/mod_cern_meta.so...(no
debugging symbols found)...done.
Reading symbols from /usr/local/libexec/apache/mod_expires.so...(no
debugging symbols found)...done.
Reading symbols from /usr/local/libexec/apache/mod_headers.so...(no
debugging symbols found)...done.
Reading symbols from /usr/local/libexec/apache/mod_usertrack.so...(no
debugging symbols found)...done.
Reading symbols from /usr/local/libexec/apache/mod_unique_id.so...(no
debugging symbols found)...done.
Reading symbols from /usr/local/libexec/apache/mod_setenvif.so...(no
debugging symbols found)...done.
Reading symbols from /usr/local/libexec/apache/libphp4.so...done.
Reading symbols from /usr/lib/libpam.so.1...done.
Reading symbols from /usr/local/lib/mysql/libmysqlclient.so.10...done.
Reading symbols from /usr/lib/libz.so.2...done.
Reading symbols from /usr/lib/libm.so.2...done.
---Type <return> to continue, or q <return> to quit---
Reading symbols from /usr/libexec/ld-elf.so.1...done.
#0 0x28230054 in zif_defined (ht=135105076, return_value=0x0,
this_ptr=0xbfbffa34, return_value_used=134541599)
at zend_builtin_functions.c:475
475 ZEND_WRONG_PARAM_COUNT();
(gdb) bt
#0 0x28230054 in zif_defined (ht=135105076, return_value=0x0,
this_ptr=0xbfbffa34, return_value_used=134541599)
at zend_builtin_functions.c:475
#1 0x804f149 in ap_clear_pool ()
#2 0x804f1ac in ap_destroy_pool ()
#3 0x804f134 in ap_clear_pool ()
#4 0x804f1ac in ap_destroy_pool ()
#5 0x80597fc in clean_parent_exit ()
#6 0x805bcc5 in standalone_main ()
#7 0x805c0fb in main ()
#8 0x804eb7d in _start ()
---
Then I did the whole thing again without --march=pentiumpro and no
other optimizations. This time it crashed with signal 11 like I was
used to:
---
s1# gdb /usr/local/sbin/httpd httpd.core
GNU gdb 4.18
Copyright 1998 Free Software Foundation, Inc.
GDB is free software, covered by the GNU General Public License, and
you are
welcome to change it and/or distribute copies of it under certain
conditions.
Type "show copying" to see the conditions.
There is absolutely no warranty for GDB. Type "show warranty" for
details.
This GDB was configured as "i386-unknown-freebsd"...(no debugging
symbols found)...
Core was generated by `httpd'.
Program terminated with signal 11, Segmentation fault.
#0 0x804f149 in ap_clear_pool ()
(gdb) bt
#0 0x804f149 in ap_clear_pool ()
#1 0x804f1ac in ap_destroy_pool ()
#2 0x804f134 in ap_clear_pool ()
#3 0x804f1ac in ap_destroy_pool ()
#4 0x80597fc in wait_or_timeout ()
#5 0x805bcc5 in main ()
#6 0x805c0fb in byterange_boundary ()
#7 0x804eb7d in _start ()
---
Then I tried a gdb /usr/local/sbin/httpd followed by run -X and
accessed the script again:
---
s1# gdb /usr/local/sbin/httpd
GNU gdb 4.18
Copyright 1998 Free Software Foundation, Inc.
GDB is free software, covered by the GNU General Public License, and
you are
welcome to change it and/or distribute copies of it under certain
conditions.
Type "show copying" to see the conditions.
There is absolutely no warranty for GDB. Type "show warranty" for
details.
This GDB was configured as "i386-unknown-freebsd"...(no debugging
symbols found)...
(gdb) run -X
Starting program: /usr/local/sbin/httpd -X
(no debugging symbols found)...
Program received signal SIGSEGV, Segmentation fault.
0x28218372 in execute (op_array=0x0) at ./zend_execute.c:1602
1602
EX(Ts)[EX(opline)->result.u.var].var.ptr->is_ref = 0;
(gdb)
--
(I guess "no debugging symbols found" was because there were no debug
symbols in apache, only in PHP)
...the same error that the poster before me got - no more useful
information. Maybe it was just random that the first time it crashed
with signal 4? I don't know...
Another FreeBSD-4.5-RELEASE-p4 machine which still has PHP 4.1.2
running (with Apache 1.3.24, too) does not experience this problem at
all.
Please let me know if there's anything else I can do to help eliminate
this bug.
Thanks,
Manuel Kasper
Previous Comments:
------------------------------------------------------------------------
[2002-05-07 09:59:34] [EMAIL PROTECTED]
Hi,
I am having extremely similair failure with PHP-4.2.0 on at least 2
FreeBSD-systems.
May 7 14:27:53 spock /kernel: pid 58939 (httpd), uid 0: exited on
signal 11
I was trying to get a fresh install of Ariadne (a PHP-based CMS
http://ariadne.muze.nl) going when i encountered these problems.
The exact same script (install.php) seems to consitently bomb at the
same location over and over again, though it does so at different
locations depending on wether it's run from Apache or from command-line
php.
I have compiled a command-line version of PHP with --enable-debug and
managed to get the following "Backtrace":
spock# gdb /usr/local/bin/php ./php.core
GNU gdb 4.18
Copyright 1998 Free Software Foundation, Inc.
GDB is free software, covered by the GNU General Public License, and
you are
welcome to change it and/or distribute copies of it under certain
conditions.
Type "show copying" to see the conditions.
There is absolutely no warranty for GDB. Type "show warranty" for
details.
This GDB was configured as "i386-unknown-freebsd"...
Core was generated by `php'.
Program terminated with signal 11, Segmentation fault.
Reading symbols from /usr/lib/libpam.so.1...done.
Reading symbols from /usr/local/lib/libc-client4.so.8...done.
Reading symbols from /usr/local/lib/libsablot.so.67...done.
Reading symbols from /usr/local/lib/libiconv.so.3...done.
Reading symbols from /usr/local/lib/libexpat.so.2...done.
Reading symbols from /usr/lib/libhistory.so.4...done.
Reading symbols from /usr/lib/libreadline.so.4...done.
Reading symbols from /usr/lib/libncurses.so.5...done.
Reading symbols from /usr/local/lib/libpq.so.2...done.
Reading symbols from /usr/local/lib/mysql/libmysqlclient.so.10...done.
Reading symbols from /usr/local/lib/libmhash.so.2...done.
Reading symbols from /usr/local/lib/libmcrypt.so.7...done.
Reading symbols from /usr/local/lib/libltdl.so.1...done.
Reading symbols from /usr/lib/libcrypt.so.2...done.
Reading symbols from /usr/local/lib/libintl.so.2...done.
Reading symbols from /usr/lib/libz.so.2...done.
Reading symbols from /usr/lib/libm.so.2...done.
Reading symbols from /usr/local/lib/libxml2.so.5...done.
Reading symbols from /usr/lib/libssl.so.2...done.
Reading symbols from /usr/lib/libcrypto.so.2...done.
Reading symbols from /usr/local/lib/libcurl.so.2...done.
Reading symbols from /usr/lib/libbz2.so.1...done.
Reading symbols from /usr/lib/libc.so.4...done.
Reading symbols from /usr/libexec/ld-elf.so.1...done.
#0 0x81352c1 in execute (op_array=0x0) at ./zend_execute.c:1602
1602
EX(Ts)[EX(opline)->result.u.var].var.ptr->is_ref = 0;
(gdb) bt
#0 0x81352c1 in execute (op_array=0x0) at ./zend_execute.c:1602
(gdb) print execute_data
$1 = {opline = 0x0, function_state = {function_symbol_table = 0x0,
function = 0x0, reserved = {0x0, 0x0, 0x0, 0x0}}, fbc = 0x0, object =
{ptr = 0x0}, Ts = 0x0, original_in_execution = 0 '\000'}
I realise this is about the shortest backtrace i have ever managed to
get out of any core dump ... but i hope it will be helpful anyhow.
--
Pascal Hofstee <[EMAIL PROTECTED]>
------------------------------------------------------------------------
[2002-05-06 13:17:49] [EMAIL PROTECTED]
I unfortunately can not rebuild PHP with --enable-debug (no access
privaleges), so I can not debug from httpd. I have built a stand alone
version with debug enabled and tested it on a few scripts.
I have isolated one script that very consistently craps out when run
from httpd or from command line. Httpd error log reports the
following:
[Mon May 6 10:01:45 2002] [notice] child pid 81412 exit signal Bus
error (10)
When the same script is run from command line, no core is dumped. When
running the script with gdb, it ends with no stack:
(gdb) run send.php
Starting program: /usr/home/ise/bin/php send.php
X-Powered-By: PHP/4.2.0
Content-type: text/html
Program exited with code 0377.
(gdb) bt
No stack.
When the script is run from PHP 4.1.2 command line, the output is as
expected: the desired HTML output.
------------------------------------------------------------------------
[2002-05-03 10:35:36] [EMAIL PROTECTED]
To properly diagnose this bug, 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".
------------------------------------------------------------------------
[2002-05-03 10:34:24] [EMAIL PROTECTED]
Hi,
Ever since my system administrator upgraded to 4.2.0, it seems that PHP
is crapping out on arbitrary pages. I have tried to isolate the source
of the crash, but have had little success. As well, I am unable to do
a gdb backtrace, as PHP is not configured with --enable-debug. So,
this bug report is probably of little value, but I'll tell you what i
know.
The Apache error log is spitting out the following:
[Fri May 3 07:21:30 2002] [notice] child pid 50301 exit signal Bus
error (10)
[Fri May 3 07:21:31 2002] [notice] child pid 51448 exit signal
Segmentation fault (11)
There doesn't seem to be a logic to what scripts makes PHP choke, as
one script might run fine once but not another time. To be clear, this
bug is not effecting scripts on my site across the boards, but again
there doesn't apear to be a logic to the scripts that are effected.
As noted in the week 84 Zend Summary, my sysop rebuilt PHP using the
configuration file noted. This did not resolve the issue.
We are running Server Version: Apache/1.3.24 (Unix) mod_gzip/1.3.19.1a
PHP/4.2.0 mod_throttle/3.1.2
I hope this measily bug report is somewhat helpful.
------------------------------------------------------------------------
--
Edit this bug report at http://bugs.php.net/?id=16994&edit=1
