ID: 23038
Comment by: hewei at ied dot org dot cn
Reported By: black at sunshine dot krneki dot org
Status: Verified
Bug Type: Scripting Engine problem
Operating System: linux debian
PHP Version: 4.3.3RC2-dev
New Comment:

The following message is what I send to PHP's developer list on Jun 18.
It was never confirmed by anyone for whether my ysis 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 ysis. 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 cirstances.

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


Previous Comments:
------------------------------------------------------------------------

[2003-07-27 14:30:21] [email]iliaaphp.net[/email]

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.

------------------------------------------------------------------------

[2003-06-23 18:02:59] [email]sniperphp.net[/email]

Andrei, can you take a look please..?


------------------------------------------------------------------------

[2003-06-23 17:35:43] black at sunshine dot krneki dot org

Got Result:

Doing bar as foo ...
Array
(
[bar] => Array
(
[methods] => Array
(
[0] => doit
)

[properties] => Array
(
)

)

)
Doing bar as foo ...

i know the get_class() returns wrong classname on second hit, as it
returns 'foo' instead of 'foobar'.

Expected result should be:

Doing bar as foo ...
Doing bar as foobar ...

Clear enough for you, sniper, buddy? (sorry about this taunt)

------------------------------------------------------------------------

[2003-06-23 17:25:27] [email]sniperphp.net[/email]

Not enough info (as in: what was the expected result, etc..etc..)


------------------------------------------------------------------------

[2003-06-21 09:17:30] hewei at ied dot org dot cn

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

?>

------------------------------------------------------------------------

The remainder of the comments for this report are too long. To view
the rest of the comments, please view the bug report online at
[url]http://bugs.php.net/23038[/url]

--
Edit this bug report at [url]http://bugs.php.net/?id=23038&edit=1[/url]