Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:12717
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Date: Fri, 10 Sep 2004 16:23:41 +0000
To: php-dev <internals@lists.php.net>
Message-ID: <20040910162341.GK58353@bagend.shire>
Mail-Followup-To: php-dev <internals@lists.php.net>
References: <20040910095725.257bcb8e.tony2001@phpclub.net>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <20040910095725.257bcb8e.tony2001@phpclub.net>
User-Agent: Mutt/1.4.1i
Subject: Re: [PHP-DEV] [patch] Zend/zend_objects_API.c - bug #29980 (segfault while executing __destruct())
From: curt@php.net (Curt Zirzow)

* 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.


Curt
-- 
First, let me assure you that this is not one of those shady pyramid schemes
you've been hearing about.  No, sir.  Our model is the trapezoid!