Re: [patch] Zend/zend_objects_API.c - bug #29980 (segfault while executing __destruct())
| From: | Andrey Hristov | Date: | Fri, 10 Sep 2004 22:22:46 +0000 |
| Subject: | Re: [patch] Zend/zend_objects_API.c - bug #29980 (segfault while executing __destruct()) | ||
| References: | 1 2 | Groups: | php.internals |
| Request: | Send a blank email to internals+get-12727@lists.php.net to get a copy of this message | ||
Curt Zirzow wrote:
* Thus wrote Antony Dovgal:may fail but a try is better than nothing. AndreyAnd 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