ID: 16994 Updated by: [EMAIL PROTECTED] Reported By: [EMAIL PROTECTED] -Status: Open +Status: Closed Bug Type: Scripting Engine problem Operating System: FreeBSD 4.5 PHP Version: 4.2.0 New Comment:
Thank you for your bug report. This issue has already been fixed in the latest released version of PHP, which you can download at http://www.php.net/downloads.php Previous Comments: ------------------------------------------------------------------------ [2002-05-14 02:11:23] [EMAIL PROTECTED] Problem solved (at least for me). Either upgrade to PHP 4.2.1 or upgrade your ports collection which now includes a patch for PHP 4.2.0. It was caused by a mkdir() in my script which triggered a FreeBSD-specific bug in PHP. (http://www.freebsd.org/cgi/query-pr.cgi?pr=37825) Greets, Manuel ------------------------------------------------------------------------ [2002-05-11 07:38:23] [EMAIL PROTECTED] 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 ------------------------------------------------------------------------ [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]> ------------------------------------------------------------------------ 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/16994 -- Edit this bug report at http://bugs.php.net/?id=16994&edit=1
