php.net |  support |  documentation |  report a bug |  advanced search |  search howto |  statistics |  random bug |  login
Bug #23196 Strange Core Dumps
Submitted: 2003-04-14 01:53 UTC Modified: 2003-06-01 20:14 UTC
From: dave at socrates dot thinkhost dot com Assigned:
Status: Closed Package: CGI/CLI related
PHP Version: 4.3.2RC2 OS: FreeBSD 4.8-STABLE
Private report: No CVE-ID: None
 [2003-04-14 01:53 UTC] dave at socrates dot thinkhost dot com
I built a new PHP DSO and CGI for one of our FreeBSD machines. The odd thing is that the "same" (built with the same configure command) CGI binary works on a similar machine without error.

The PHP CGI works fine when called from the shell, but dies and dumps a core when called by suexec (apache). A back trace of the core dump is included below:

================================================

Core was generated by `php'.
Program terminated with signal 11, Segmentation fault.
Reading symbols from /usr/lib/libcrypt.so.2...done.
Reading symbols from /usr/local/lib/libmcal.so...done.
Reading symbols from /usr/local/lib/libc-client4.so.8...done.
Reading symbols from /usr/local/lib/libssl.so.4...done.
Reading symbols from /usr/local/lib/libcrypto.so.4...done.
Reading symbols from /usr/local/lib/libexpat.so.4...done.
Reading symbols from /usr/local/lib/libpq.so.2...done.
Reading symbols from /usr/local/lib/libpdf.so.4...done.
Reading symbols from /usr/lib/libm.so.2...done.
Reading symbols from /usr/lib/libz.so.2...done.
Reading symbols from /usr/local/lib/libtiff.so.4...done.
Reading symbols from /usr/local/lib/libpng.so.5...done.
Reading symbols from /usr/local/lib/libjpeg.so.9...done.
Reading symbols from /usr/local/lib/mysql/libmysqlclient.so.10...done.
Reading symbols from /usr/local/lib/libming.so.3...done.
Reading symbols from /usr/local/lib/libmhash.so.2...done.
Reading symbols from /usr/local/lib/libmcrypt.so.8...done.
Reading symbols from /usr/local/lib/libltdl.so.1...done.
Reading symbols from /usr/local/lib/libldap.so.2...done.
Reading symbols from /usr/local/lib/liblber.so.2...done.
Reading symbols from /usr/lib/libpam.so.1...done.
Reading symbols from /usr/local/lib/libiconv.so.3...done.
Reading symbols from /usr/local/lib/libintl.so.4...done.
Reading symbols from /usr/local/lib/libgd.so.2...done.
Reading symbols from /usr/local/lib/libfreetype.so.9...done.
Reading symbols from /usr/local/lib/libcurl.so.2...done.
Reading symbols from /usr/local/lib/libxml2.so.5...done.
Reading symbols from /usr/lib/libc.so.4...done.
Reading symbols from /usr/lib/libssl.so.3...done.
Reading symbols from /usr/lib/libcrypto.so.3...done.
Reading symbols from /usr/local/lib/libssl.so.3...done.
Reading symbols from /usr/local/lib/libcrypto.so.3...done.
Reading symbols from /usr/libexec/ld-elf.so.1...done.
#0  0x8176b76 in _estrdup (s=0x0) at /usr/local/src/php-4.3.2RC1/Zend/zend_alloc.c:337
337             length = strlen(s)+1;

Patches

Add a Patch

Pull Requests

Add a Pull Request

History

AllCommentsChangesGit/SVN commitsRelated reports
 [2003-04-21 12:56 UTC] sniper@php.net
Most likely just broken system (hardware or compile tools)

 [2003-04-22 14:12 UTC] dave at socrates dot thinkhost dot com
Okay, I CVSup'ed the FreeBSD source, and made a new world and kernel. I also download a fresh copy of the 4.3.2RC1 source.

I noticed during the configure command output, that bison was missing, so I added bison from the ports, and re-build the php CGI binary.

Same problem. We are a RackSpace customer, and the hardware seems fine. We built everything else in the system using the same build tools, but only the PHP CGI is broken. As I mentioned, it works from the shell, but has trouble when called by suexec.

How do I fix this problem? I am running out of ideas...
 [2003-04-22 16:12 UTC] dave at socrates dot thinkhost dot com
My solution to the problem for the time being is to re-compile using the 4.3.1 source, which built a working PHP CGI binary (There goes your theory about hardware/compiler problems?).

I've spent the afternoon trying everything I can think of, all signs point to this problem being specific to the 4.3.2RC1 source tree. I am going to wait for the next version of PHP that is not RC grade.

Also note that I built a "minimal" PHP CGI (with a very limited set of configure commands, to rule out the extensions as the cause of the problem), and it dumped a core which revealed the same end result in the back trace as the one I have already posted.
 [2003-04-23 03:27 UTC] sniper@php.net
Try this configure line:

./configure --disable-all

 [2003-04-23 15:11 UTC] dave at socrates dot thinkhost dot com
Same thing!

Core was generated by `php'.
Program terminated with signal 11, Segmentation fault.
Reading symbols from /usr/lib/libcrypt.so.2...done.
Reading symbols from /usr/lib/libm.so.2...done.
Reading symbols from /usr/lib/libc.so.4...done.
Reading symbols from /usr/libexec/ld-elf.so.1...done.
#0  0x80bd4b2 in _estrdup (s=0x0) at /usr/local/src/php-4.3.2RC1/Zend/zend_alloc.c:337
337             length = strlen(s)+1;

The writing on the wall does not get any more clear.
 [2003-04-24 04:06 UTC] sniper@php.net
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.

Get the latest STABLE cvs snapshot first.
(and configure with --enable-debug)

 [2003-04-29 10:20 UTC] sniper@php.net
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-04-29 11:29 UTC] dave at socrates dot thinkhost dot com
Core was generated by `php'.
Program terminated with signal 11, Segmentation fault.
Reading symbols from /usr/lib/libcrypt.so.2...done.
Reading symbols from /usr/lib/libm.so.2...done.
Reading symbols from /usr/lib/libc.so.4...done.
Reading symbols from /usr/libexec/ld-elf.so.1...done.
#0  0x28202975 in strlen () from /usr/lib/libc.so.4

4.3.1 Source works fine.
4.3.2RC1 and latest CVS Snap produce the above

What is wrong?
 [2003-04-29 13:45 UTC] wez@php.net
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.

lets have a better backtrace (we need to see more than just the top frame), and a short, self-contained reproducing script.
 [2003-04-29 20:13 UTC] dave at socrates dot thinkhost dot com
I am sorry the rest of the backtrace was missing, here is everything:

Core was generated by `php'.
Program terminated with signal 11, Segmentation fault.
Reading symbols from /usr/lib/libcrypt.so.2...done.
Reading symbols from /usr/lib/libm.so.2...done.
Reading symbols from /usr/lib/libc.so.4...done.
Reading symbols from /usr/libexec/ld-elf.so.1...done.
#0  0x28202975 in strlen () from /usr/lib/libc.so.4
(gdb) bt
#0  0x28202975 in strlen () from /usr/lib/libc.so.4
#1  0xbfbff528 in ?? ()
#2  0x8162ddb in init_request_info () at /usr/local/src/php-4.3.2RC/sapi/cgi/cgi_main.c:709
#3  0x81636bb in main (argc=31, argv=0xbfbff4a8) at /usr/local/src/php-4.3.2RC/sapi/cgi/cgi_main.c:1238
#4  0x806006a in _start ()
 [2003-04-30 06:21 UTC] sniper@php.net
how did you configure it in httpd.conf?
what query crashes it?

 [2003-04-30 07:17 UTC] dave at socrates dot thinkhost dot com
This is the CGI, so there is no httpd.conf config that affects it.

The crash below was produced from a very simple script:

<?php
  phpinfo();
?>
 [2003-04-30 07:19 UTC] dave at socrates dot thinkhost dot com
Relevant lines from httpd.conf:

AddType application/x-httpd-php .php .php4 .php3 .phtml
AddType application/x-httpd-php-source .phps

mod_gzip_item_include file \.php$
mod_gzip_item_include mime ^application/x-httpd-php
 [2003-05-06 11:27 UTC] dave at socrates dot thinkhost dot com
I have tried the new PHP-4.3.2RC2 source, and the problem still persists, here is the back trace from the PHP CGI binary built from the PHP-4.3.2RC2 source tree:

Core was generated by `php'.
Program terminated with signal 11, Segmentation fault.
Reading symbols from /usr/lib/libcrypt.so.2...done.
Reading symbols from /usr/local/lib/libmcal.so...done.
Reading symbols from /usr/local/lib/libc-client4.so.8...done.
Reading symbols from /usr/local/lib/libexpat.so.4...done.
Reading symbols from /usr/local/lib/libpq.so.2...done.
Reading symbols from /usr/local/lib/libpdf.so.4...done.
Reading symbols from /usr/lib/libz.so.2...done.
Reading symbols from /usr/local/lib/libtiff.so.4...done.
Reading symbols from /usr/local/lib/libpng.so.5...done.
Reading symbols from /usr/local/lib/libjpeg.so.9...done.
Reading symbols from /usr/local/lib/mysql/libmysqlclient.so.10...done.
Reading symbols from /usr/local/lib/libming.so.3...done.
Reading symbols from /usr/lib/libm.so.2...done.
Reading symbols from /usr/local/lib/libmhash.so.2...done.
Reading symbols from /usr/local/lib/libmcrypt.so.8...done.
Reading symbols from /usr/local/lib/libltdl.so.1...done.
Reading symbols from /usr/local/lib/libldap.so.2...done.
Reading symbols from /usr/local/lib/liblber.so.2...done.
Reading symbols from /usr/lib/libpam.so.1...done.
Reading symbols from /usr/local/lib/libintl.so.4...done.
Reading symbols from /usr/local/lib/libgd.so.2...done.
Reading symbols from /usr/local/lib/libfreetype.so.9...done.
Reading symbols from /usr/local/lib/libcurl.so.2...done.
Reading symbols from /usr/local/lib/libxml2.so.5...done.
Reading symbols from /usr/local/lib/libiconv.so.3...done.
Reading symbols from /usr/lib/libc.so.4...done.
Reading symbols from /usr/lib/libssl.so.3...done.
Reading symbols from /usr/lib/libcrypto.so.3...done.
Reading symbols from /usr/local/lib/libssl.so.3...done.
Reading symbols from /usr/local/lib/libcrypto.so.3...done.
Reading symbols from /usr/local/lib/libssl.so.4...done.
Reading symbols from /usr/local/lib/libcrypto.so.4...done.
Reading symbols from /usr/local/Zend/lib/ZendOptimizer.so...done.
Reading symbols from /usr/libexec/ld-elf.so.1...done.
#0  0x81901de in _estrdup (s=0x0) at
/usr/local/src/php-4.3.2RC2/Zend/zend_alloc.c:363
363             length = strlen(s)+1;
(gdb) bt
#0  0x81901de in _estrdup (s=0x0) at
/usr/local/src/php-4.3.2RC2/Zend/zend_alloc.c:363
#1  0x81b24e5 in init_request_info () at
/usr/local/src/php-4.3.2RC2/sapi/cgi/cgi_main.c:709
#2  0x81b2b57 in main (argc=30, argv=0xbfbff5ec) at
/usr/local/src/php-4.3.2RC2/sapi/cgi/cgi_main.c:1238
#3  0x808cb56 in _start ()
(gdb) quit
 [2003-05-06 13:35 UTC] msopacua at idg dot nl
Can't reproduce this with 4.8-STABLE and how did you ever get an argc of 30?

Can you type the following in gdb:
frame 2
followed by:
info local

Also:
/path/to/cgibinary/php -f /path/to/phpinfo.php

should give you an argc of three, where argv[2] should be the filename and argv[3] should be NULL (check by print argv[2] and print argv[3] respectively).
 [2003-05-06 16:25 UTC] dave at socrates dot thinkhost dot com
> Also:
> /path/to/cgibinary/php -f /path/to/phpinfo.php

As I already mentioned, it works fine from the shell, this problem only occurs when the execution is called by suexec.

I can call the script directly (since it has executable perms) like so:
./info.php

and like so:
/usr/local/bin/php -f ./info.php

both work fine, but not when called by suexec (Apache).

> Can you type the following in gdb:
> frame 2
> followed by:
> info local

(gdb) bt
#0  0x81901de in _estrdup (s=0x0) at /usr/local/src/php-4.3.2RC2/Zend/zend_alloc.c:363
#1  0x81b24e5 in init_request_info () at /usr/local/src/php-4.3.2RC2/sapi/cgi/cgi_main.c:709
#2  0x81b2b57 in main (argc=30, argv=0xbfbff4e8) at /usr/local/src/php-4.3.2RC2/sapi/cgi/cgi_main.c:1238
#3  0x808cb56 in _start ()
(gdb) frame 2
#2  0x81b2b57 in main (argc=30, argv=0xbfbff4e8) at /usr/local/src/php-4.3.2RC2/sapi/cgi/cgi_main.c:1238
1238                    init_request_info(TSRMLS_C);
(gdb) info local
orig_bailout = {{_jb = {0 <repeats 12 times>}}}
exit_status = 0
cgi = 1
c = 0
i = 30
len = 137233484
file_handle = {type = 100 'd',
  filename = 0xbfbff4e8 "D???I???R???e???\210???\032???=???X???s???\220???????7???K???r???\221???????????????\005???*???M???\\???????0???N???h???\201???\224???????????",
  opened_path = 0x0, handle = {fd = 674015744, fp = 0x282caa00}, free_filename = 224 '?'}
retval = -1
s = 0x82e044c "?\a"
behavior = 1
no_headers = 0
orig_optind = 1
orig_optarg = 0x0
script_file = 0x0
global_vars = {head = 0x282b0aab, tail = 0x282c9240, size = 0, count = 3217028236, dtor = 0x282b0a47 <_rtld_bind+59>, persistent = 30 '\036', traverse_ptr = 0xbfbff4e8}
(gdb)

This is strange, it doesn't occur on any of the other production machines at work (which are all 4.8-STABLE as well). It also works fine on my personal server (4.8-RC). However, I can get it to work on the "problem" machine when I compile from the 4.3.1 or earlier source tree.
 [2003-05-15 13:28 UTC] sniper@php.net
Happens on just a one machine.
Can not be PHP bug.

 [2003-06-01 20:14 UTC] dave at socrates dot thinkhost dot com
I just wanted to follow up on this, to give the issue closure.

After updating to PHP-4.3.2 [final] the problem has mysteriously disappeared. I have made no other significant changes to the box itself. I have no idea what was changed, I'm just happy it has since been resolved. Thanks guys.
 
PHP Copyright © 2001-2024 The PHP Group
All rights reserved.
Last updated: Thu Mar 28 13:01:28 2024 UTC