I'm tempted to bogusify this right away since you only 
assume a lot here. Please provide real information we can
work with..like a simple example script.

(and FYI: there is no such thing as 4.5-dev officially)

according to http://snaps.php.net there is? 
 
and yeah, i guess you could mark it as bogus, as far as "simple" 
scripts go, i doubt i could ever reproduce this in a simple one.. even 
the collection of code i use has about 170k just core files (and its 
clean non bloated code if you believe it ;)).. 
 
the best i can do is give you a cvs snapshot of a week ago when the 
bug was still occuring.. after i removed aggregate i havent had a 
crash.. 
 
as for my debugging knowledge goes, its pretty much what i gathered 
from this page, and you cant really expect me to master gdb and 
valgrind without experience with any of them before. 
 
if you want to give it a shot then by all means, im willing to give you 
everything that is in my power to do so, a short example script 
however, is not. 

just letting you know that its been a week now with not a single crash 
after removing aggregate - contact me when/if you want/need the db 
dump and code dump to analyze this/test it. 

This short script can reproduce the aggregation bug I reported above.

class bar {
 
   function doit()
   {
      print " Doing...\n";
   }
}


class foo {

   function foo()
   {
       print_r(aggregation_info($this));
       aggregate($this, "bar");
   }
   
   function spawn()
   {
       return new foo();
   }
}

$a = new foo();
$a->doit();
$b = $a->spawn();
$b->doit();
unset($a);
$c = $b->spawn();
$c->doit();

Besides 'unset($a)', '$a = new foo()' will also cause the same problem.

This bug has been fixed in CVS.

In case this was a PHP problem, 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/.
 
In case this was a documentation problem, the fix will show up soon at
http://www.php.net/manual/.

In case this was a PHP.net website problem, the change will show
up on the PHP.net site and on the mirror sites in short time.
 
Thank you for the report, and for helping us make PHP better.

The bug is not fixed. Run the following script either before or after applying andrei's recent patch, one will reproduct the bug.
<?php

class bar {
 
   function doit()
   {
      print "Doing bar as " . get_class($this) . " ...\n";
   }
}

class foo {

   function foo()
   {
       print_r(aggregation_info($this));
       aggregate($this, "bar");
   }
}

class foobar extends foo {
}

$a = new foo();
$a->doit();

unset($a);

$b = new foobar();
$b->doit();

?>

This problem has little to do with aggregation functions. This is a ZE scripting language problem. This can be demonstrated by adding var_dump(get_class($this)) inside the foo constructor. It'll always print "foo", the name of the class for the class the constructor is for, not the 'real' class.

The following message is what I send to PHP's developer list on Jun 18. It was never confirmed by anyone for whether my analysis was correct or not. 

My conclusion could be very possibily wrong as my understanding to PHP/Zend sources was still very shallow.
I just hope it may provide useful information for anyone on further studying of this bug.

I still hope Andrei or someone else that knows something can confirm this. I spent quite sometime trying to find out if I can do something on this bug as my contribution of PHP.
----------------------------------------------------------

According to my deeper analysis. Unsetting an object will not touch any thing related to the object execpt remove it from the active symbol table. And the same memory location(or handle) will be reallocated to the next new object in some circumstances.

If so, aggregate.c will have a problem as it keeps an external hash on the objects' handle and their aggregation information. Then when an object is unset, there is no way to inform aggregate.c (or any other extensions doing the similar thing) to remove the corresponding item from it's hash. And the next new object happened to use the same memory location will still be regarded as the original one by aggregate.c. That's why the above script will print a wong class name. Also because the old object was aggregated, the aggregate.c will refuse to perform aggregation on it.

So I guess it is not easy to fix the bug unless a patch is made to Zend codes to add a hook for aggregate.c to deaggregate an object when unsetting (or maybe in some other places, like assigning it with a same object).

Although the ChangeLog says that this bug has been fixed,
my above script still doesn't work as expected.

aggregate does not exist in PHP 5. And as we're focusing on PHP 5 development, this is now 'wont fix' for PHP 4.