Most likely just broken system (hardware or compile tools)

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...

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.

Try this configure line:

./configure --disable-all

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.

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)

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.

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?

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.

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 ()

how did you configure it in httpd.conf?
what query crashes it?

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();
?>

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

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

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).

> 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.

Happens on just a one machine.
Can not be PHP bug.

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.