php.net |  support |  documentation |  report a bug |  advanced search |  search howto |  statistics |  random bug |  login
Bug #16994 Error log reports seg fault and bus error at what seems to be arbitrary moments
Submitted: 2002-05-03 10:34 UTC Modified: 2002-05-14 02:33 UTC
Votes:2
Avg. Score:4.5 ± 0.5
Reproduced:2 of 2 (100.0%)
Same Version:2 (100.0%)
Same OS:2 (100.0%)
From: michael at eggplant dot ws Assigned:
Status: Closed Package: Scripting Engine problem
PHP Version: 4.2.0 OS: FreeBSD 4.5
Private report: No CVE-ID: None
View Add Comment Developer Edit
Welcome! If you don't have a Git account, you can't do anything here.
You can add a comment by following this link or if you reported this bug, you can edit this bug over here.
(description)
Block user comment
Status: Assign to:
Package:
Bug Type:
Summary:
From: michael at eggplant dot ws
New email:
PHP Version: OS:

 

 [2002-05-03 10:34 UTC] michael at eggplant dot ws
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.

Patches

Add a Patch

Pull Requests

Add a Pull Request

History

AllCommentsChangesGit/SVN commitsRelated reports
 [2002-05-03 10:35 UTC] mfischer@php.net
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-06 13:17 UTC] michael at eggplant dot ws
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-07 09:59 UTC] pascal at emaxx dot nl
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 <pascal@emaxx.nl>
 [2002-05-11 07:38 UTC] mk at neon1 dot net
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-14 02:11 UTC] mk at neon1 dot net
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-14 02:33 UTC] derick@php.net
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


 
PHP Copyright © 2001-2024 The PHP Group
All rights reserved.
Last updated: Tue May 21 08:01:31 2024 UTC