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 for *NIX and
http://bugs.php.net/bugs-generating-backtrace-win32.php for Win32

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.

What is the difference between these two servers?

The following produces a segfault:

<?

function function_call($arg1, $arg2, $arg3) {}

$arr1 = array(1, 2, 3);
$arr2 = array(4, 5, 6);
$arr3 = array(7, 8, 9);

$arr = function_call($arr1, $arr2, $arr3);

echo "done";

?>

If you echo something and exit inside the function, it does not segfault.

(gdb) run -X
Starting program: /usr/local/apache/bin/httpd -X
(no debugging symbols found)
(no debugging symbols found)
(no debugging symbols found)
[Thread debugging using libthread_db enabled]
[New Thread -1218542944 (LWP 8821)]
Processing config directory: /usr/local/apache/conf/vhosts/*.conf
 Processing config file: /usr/local/apache/conf/vhosts/dev-apache.conf
 Processing config file: /usr/local/apache/conf/vhosts/empty.conf
Processing config directory: /etc/httpd/conf.d/*.conf
 Processing config file: /etc/httpd/conf.d/apt-proxy.conf
 Processing config file: /etc/httpd/conf.d/monitor.conf
 Processing config file: /etc/httpd/conf.d/nagios.conf
[Tue Dec  5 15:49:35 2006] [warn] NameVirtualHost *:80 has no VirtualHosts

Program received signal SIGSEGV, Segmentation fault.
[Switching to Thread -1218542944 (LWP 8821)]
0x080e294e in _zval_ptr_dtor ()
(gdb) bt
#0  0x080e294e in _zval_ptr_dtor ()
#1  0x08109698 in zend_get_zval_ptr_ptr ()
#2  0x08108b28 in execute ()
#3  0x080eecae in zend_execute_scripts ()
#4  0x080b6161 in php_execute_script ()
#5  0x0814fa6a in apache_php_module_main ()
#6  0x080ac6b8 in ap_get_server_built ()
#7  0x080abc71 in ap_get_server_built ()
#8  0x083f0043 in ap_invoke_handler ()
#9  0x08409857 in ap_update_mtime ()
#10 0x08408941 in ap_process_request ()
#11 0x0840179e in suck_in_ap_validate_password ()
#12 0x083fff68 in suck_in_ap_validate_password ()
#13 0x083fef95 in suck_in_ap_validate_password ()
#14 0x083fcb26 in main ()
(gdb)

Please try using this CVS snapshot:

  http://snaps.php.net/php5.2-latest.tar.gz
 
For Windows:
 
  http://snaps.php.net/win32/php5.2-win32-latest.zip

I'm downloading the CVS version now.  I neglected to --enable-debug when generating the backtrace.  When it was enabled, the problem didn't occur, however.  I will update again after trying the latest CVS.

Ok, great.

It still happens with the CVS version.

What is the difference between these two servers?
Could you try to run this code with CLI and valgrind?

The problem actually occurs on several different machines, whenever I use the RPM built with those configure options.  I've tried it on a 2.4 GHz Celeron, a 1 GHz Duron, and a 2.66 GHz P4.  Using my alternate RPM that has the other configure options, I don't see the problem.

That's fortunate, because the one without the problem is the one on all of my production machines.  The problem only happens on my monitoring machine.

The problem does not happen in CLI, however the configure options are (yet again) different.  I have three different CLI versions, and it works with all three.  Here are their configure options:

'./configure' '--mandir=/usr/share/man' '--with-config-file-path=/etc/php' '--with-config-file-scan-dir=/etc/php/cli.d' '--with-mysql=/usr' '--with-mysqli=/usr/bin/mysql_config' '--with-zlib' '--enable-mbstring' '--with-openssl' '--disable-cgi' '--enable-pcntl' '--without-pear' '--enable-soap' '--with-rrdtool' '--with-snmp' '--with-gmp' '--without-spl' '--without-sqlite' '--without-pdo'

'./configure' '--mandir=/usr/share/man' '--with-config-file-path=/etc/php' '--with-config-file-scan-dir=/etc/php/cli.d' '--with-mysql=/usr' '--with-mysqli=/usr/bin/mysql_config' '--disable-cgi' '--enable-soap' '--with-readline' '--with-zlib' '--with-ldap' '--with-ncurses' '--with-imap' '--with-imap-ssl' '--with-kerberos=/usr/kerberos' '--with-gmp' '--without-spl' '--without-sqlite' '--without-pdo'

'./configure' '--mandir=/usr/share/man' '--with-config-file-path=/etc/php' '--with-config-file-scan-dir=/etc/php/gd.d' '--with-mysql=/usr' '--with-mysqli=/usr/bin/mysql_config' '--with-zlib' '--enable-mbstring' '--with-openssl' '--disable-cgi' '--enable-pcntl' '--without-pear' '--enable-soap' '--with-gd' '--enable-gd-native-ttf'

Please try to get some more information using valgrind (and --enable-debug).

As I stated earlier, the problem does NOT happen if I enable debug.

Yes, I know. But this just means that with valgrind you should be able to see more.
Run it this way:
USE_ZEND_ALLOC=0 valgrind --tool=memcheck php <script.php>

I have fixed the problem by changing the CFLAGS variable from "O3 -mmmx -march=i686 -mcpu=i686 -funroll-loops" to "-O3 -msse -mmmx -march=i686 -mcpu=pentium4 -mfpmath=sse -funroll-loops".  I'm not sure how that helps, but it's the only thing that fixed it.  The second one is the CFLAGS used by my other RPM build of apache+php.

It seems to me like an over-optimization bug by the compiler.