Thank you for this bug report. To properly diagnose the problem, we
need a short but complete example script to be able to reproduce
this bug ourselves. 

A proper reproducing script starts with <?php and ends with ?>,
is max. 10-20 lines long and does not require any external 
resources such as databases, etc.

If possible, make the script source available online and provide
an URL to it here. Try avoid embedding huge scripts into the report.

The segfault seems to be happening in this included file that re-configures the session handler.. I successfully had it output working code until it includes this file, it fails at the "Session_start" function:

<?php

// DAO
require_once "DAO_Session.php";


$DAO_Session =& new DAO_Session();



session_set_save_handler( array(& $DAO_Session, "dao_open"),
                          array(& $DAO_Session, "dao_close"),
                          array(& $DAO_Session, "dao_read"),
                          array(& $DAO_Session, "dao_write"),
                          array(& $DAO_Session, "dao_destroy"),
                          array(& $DAO_Session, "dao_gc"));

// I get output here;

// Fire up 
session_start();

// segfault here:  tail /apache/logs/error_log
/*
[Mon Dec 20 14:16:39 2004] [notice] child pid 11679 exit signal Segmentation fault (11)
[Mon Dec 20 14:16:41 2004] [notice] child pid 11680 exit signal Segmentation fault (11)

*/
echo "here:"  . date("Y-m-d H:i:s"); die;

class DAO_Session {

  // functions here..  can post if requested

}

I'm now getting very suspect of PEAR:DB_Dataobject.. I upgraded the version of it; as where the segfault is happening it's using a dataobject and I'm no longer getting a segfault, but rather a real php error message that something is buggered...

Thank you for this bug report. To properly diagnose the problem, we
need a short but complete example script to be able to reproduce
this bug ourselves. 

A proper reproducing script starts with <?php and ends with ?>,
is max. 10-20 lines long and does not require any external 
resources such as databases, etc.

If possible, make the script source available online and provide
an URL to it here. Try avoid embedding huge scripts into the report.

What also helps is to provide a backtrace with symbols enabled (meaning PHP in --enable-debug mode).

I'm not sure if this is a bug anymore, maybe someone else can comment..  It turns out I had to add:

define("DB_DATAOBJECT_NO_OVERLOAD", 0);

to the prepend script..  

I was under the impression that this was only required if you were using the Zend optimizer ( we are not)  .. But it seems to have fixed the issue.  I still find it odd that it works fine in 4.3.9 without that flag, and 4.3.10 needs it?

From the PEAR site i just found: 
"Pass by Reference, due to a unfixable bug in PHP4, you can not use overload with pass-by-reference arguments (It works OK in PHP5), If you need pass-by-reference, define the constant DB_DATAOBJECT_NO_OVERLOAD = 0 "

That would seem to align with the error: 

"Program received signal SIGSEGV, Segmentation fault.
0x080eb3bd in zend_assign_to_variable_reference ()"

But again why 4.3.9 works fine and 4.3.10 borks.

My problem is fixed but did a change affect something?

This bug has been fixed in CVS.

Snapshots of the sources are packaged every three hours; this change
will be in the next snapshot. You can grab the snapshot at
http://snaps.php.net/.
 
Thank you for the report, and for helping us make PHP better.