Thank you for taking the time to write to us, but this is not
a bug. Please double-check the documentation available at
http://www.php.net/manual/ and the instructions on how to report
a bug at http://bugs.php.net/how-to-report.php

This is expected, PHP does not protect against infinite recursion.

There is no recursion. This is a function being called from within a switch block. Surely?

?
You call the function segfault() in a never ending loop.

What loop??

Remove the "global $moo" and the $rar = 0 and it runs as expected:

<?
        switch($t)
        {
                default:
                        function segfault()
                        {
                                echo 'About to segfault : ';
                        }
                        segfault();
        }
        echo 'Or not. Look no loop.';
?>

There is no loop here. This is segfaulting because the function is failing to return correctly (stack corruption). Remove the "global" statement, and add an echo '' outside of the switch() braces to see normal (expected) program flow.

N.B. Original code tested and works as expected with PHP 4.3.3

I getting a seg. fault on a simple little script that's worked for years and it sure smells like stack corruption.

<?
require_once("config.inc");
require_once("Database.inc");

$db = new Database(USER_ID, USER_PASSWORD);
$db->connect();

$sql  = "select from STUDENT_STATUS ";
$sql .= "where STATUS='APPROVED' ";
?>

On my solaris 9 x86 box this seq. faults. Change the last line it seq faults. Remove the last line it doesn't. After a
hour of playing, I've discovered that I can prevent a seg. fault by place echo statements (or some other random statment) in key positions in the file.  That sure smells
like stack corruption.

I ran gdb on the core dump and the last lines of the backtrace are:

#20 0x81b65da in zend_deactivate () at /usr/local/src/php-5.0.1/Zend/zend.c:819
#21 0x8182007 in php_request_shutdown (dummy=0x0)
    at /usr/local/src/php-5.0.1/main/main.c:1212
#22 0x81db50f in main (argc=2, argv=0x8047a18)
    at /usr/local/src/php-5.0.1/sapi/cli/php_cli.c:1046

and from what little I know of gdb it looks like it's happening when php is trying to shutdown.

gdb stack trace from the first script (Ref: 3:24pm CEST)

#0  0x081e74a2 in _zval_ptr_dtor ()
#1  0x08216d9f in zend_switch_free_handler ()
#2  0x08211dff in execute ()
#3  0x0821567d in zend_do_fcall_common_helper ()
#4  0x08215993 in zend_do_fcall_by_name_handler ()
#5  0x08211dff in execute ()
#6  0x081f2b17 in zend_execute_scripts ()
#7  0x081b4d31 in php_execute_script ()
#8  0x00000000 in ?? ()
#9  0x00000003 in ?? ()
#10 0x00000000 in ?? ()
...
#970 0x5f706870 in ?? ()
#971 0x69727473 in ?? ()
#972 0x68775f70 in ?? ()
#973 0x4083a6c4 in mallopt () from /lib/libc.so.6
Previous frame inner to this frame (corrupt stack?)
(gdb)

:o)

I've noticed that this is a duplicate of bug #28487

Please try using this CVS snapshot:

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

Seems to be fixed. Please, test it again.

No feedback was provided for this bug for over a week, so it is
being suspended automatically. If you are able to provide the
information that was originally requested, please do so and change
the status of the bug back to "Open".

This is the same as bug #29944, which is fixed as of 
2005-04-25 in CVS