Hi,
I didn't receive and emails regarding to my discovery of the bug. If it
wasn't because the mailing list or my email server's problem, it would
turned out to be that nobody cares about it.
Then what if, according to my own debugging, the problem is related
to zend hash?
I guess the answer to the following error is that unset($a) freed the
object but not the all the hash tables (aggretated methods) associated
with it.
So a new object after the unset will reuse the same memory location and
zend_hash_add will return a failure.
zend_hash.c: in function zend_hash_add_or_update
while (p != NULL) {
if ((p->h == h) && (p->nKeyLength == nKeyLength)) {
if (!memcmp(p->arKey, arKey, nKeyLength)) {
if (flag & HASH_ADD) {
return FAILURE;
}
HANDLE_BLOCK_INTERRUPTIONS();
Can anyone understading zend hash functions well check why
this would happen?
Shouldn't unset($a) clean everything related to it?
Please! I can't live without aggregation and I can't
work any longer due to the bug.
If you really don't think it a bug. Would anyone kindly reply
me a message so that at least I know you guys have received my
report?
Wei He
On Fri, 23 May 2003, Wei He wrote:
> Hi,
>
> 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.
>
> Wei He
>
>
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
