Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:12727
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Message-ID: <41422936.1010001@hristov.com>
Date: Sat, 11 Sep 2004 00:22:46 +0200
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.8a3) Gecko/20040817
MIME-Version: 1.0
CC: php-dev <internals@lists.php.net>
References: <20040910095725.257bcb8e.tony2001@phpclub.net> <20040910162341.GK58353@bagend.shire>
In-Reply-To: <20040910162341.GK58353@bagend.shire>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Subject: Re: [PHP-DEV] [patch] Zend/zend_objects_API.c - bug #29980 (segfault
 while executing __destruct())
From: php@hristov.com (Andrey Hristov)

Curt Zirzow wrote:
> * Thus wrote Antony Dovgal:
> 
>>And the last one, the most questionable patch.
>>
>>ATM ZE2 calls destructor at the end of the request and no matter
>>is there were a fatal error (which should probably stop executing
>>the script).  In some cases it leads to nasty segfaults (me and
>>report's author can reproduce it, but others can't. weird..).
> 
> 
> I'm not sure if this has anything to do with it but the destructor
> is being called before the constructor actually finishes, I would
> think the state of the object itself isn't stable. I can stop the
> segfault happening if I cause the fatal error after the object is
> created.
> 
> 
>>Some persons (hello, Andrey =)) think that this could be a useful
>>feature, but for me it's just an inconsistency. IMO destructors
>>should not be called after fatal errors, because they can cause
>>even more harm.
> 
> 
> Might want to add me to that list :)  A use I can see is if the
> object manages a buffer of some sort and the destructor ensures
> that it is flushed, a bypass of the destructor would cause the
> buffer to get lost.
> 
Well, the system is in unstable state and that means that a flush
may fail but a try is better than nothing.

Andrey