Pull Requests

History

I don't know how to fix this.
BTW I don't understand what do you like to do with this code. Note that object is not destroied while someone is refering it, so if you put it into self::$instances[] it never be destroied. The test::__destruct() can only be called from test::__construct() then you update self::$instances[$this->_id]. And this makes double free() and crash.

[2006-11-08 17:28 UTC] daan at parse dot nl

Ah I was tinkering with an instances static array, which first held only the $this->_id, but then I changed it into $this (which is indeed a bit strange, I figured that out too later) - but the crash still was a crash and not some error, so hence the bugreport.

[2006-12-20 10:33 UTC] duncanh at icritical dot com

OS: CentOS 4.4
Apache: httpd-2.0.52-28.ent.centos4
PHP: PHP 5.2.0 (cli) (built: Dec 13 2006 10:13:00)
I'm seeing similar segfaults in the same area (0x0122081d
in _zend_mm_alloc_int (heap=0x8494f90, size=32)
at /root/Files/php-5.2.0/Zend/zend_alloc.c:1076), but I'm
not using destructors at all.
function Tenant($clientid) {
doDebug(6, __METHOD__."($clientid)");
doDebug(6, __METHOD__);
}
Logs show Tenant::Tenant(), and Tenant::Tenant. The
apache child then falls over in a heap. I can only assume
that somewhere in my includes, a bit of code is doing
something that the Zend code can't handle. I've trawled
through my code changes since this last worked, and
nothing obvious is showing up. I'm now working on
reducing my code to bare-bones, and building it back up
until the segfaults occur again.

[2006-12-20 10:42 UTC] daan at parse dot nl

@ duncanh at icritical dot com:
That's probably an unrelated bug, which also results in a memory related segfault.
The best thing to do is to report it as a new bug, and perhaps reference to this bug in your description.
(and of course see if you can narrow it down to single piece of code)

[2006-12-20 11:39 UTC] duncanh at icritical dot com

@ daan at parse dot nl
You were correct. I managed to write an infinite loop.
Sorry for the noise.

The bug seems to be unfixable.
In __construct() the operator self::$instances[$this->_id] = $this; executes the following sequence:
1) fetch address of self::$instances[$this->_id]
2) destroys old value
3) assigns new value into the address fetched on step (1)
but during step (2) __destruct() is called and it calls unset(self::$instances[$this->_id])
as the result, the address fetched on step (1) became invalid on step (3)