AD>>> class tables are already cleaned, etc.) - so it crashes. AD>> AD>>Looks like you're right, but why others can't reproduce this segfault?
Only idea I have they didn't run it in debug mode. In the debug mode, destroyed memory is overwritten, in the release mode it isn't. So on debug, use-after-free cases drop dead instantly, while on release mode they may very well work in some cases. AD>>Sounds nice: we should not call destructors after they were AD>>already called =) The problem is that if one of the dtors fails, others aren't called. THis is OK (i.e., this is better than the alternatives), but it confuses the engine later on the way of shutdown. AD>>I could propose a simple solution: add a global flag, which will indicate AD>>that shutdown_destructors() was called, and do appropriate check in AD>>zend_objects_store_del_ref(). AD>>Comments/objections? I personally don't like the idea of having yet another hack flag. Moveover, the del_ref is not the only place one may call destructors. What I'd do is: if one of the dtors bails out, we catch it in call_dtors and then mark all the objects as "already destroyed" - so there's no way any dtor could be called after that from any place. This is a bit slower performance-wise, bnut I'm not sure performance is much of concern in situation where the code has failed in shutdown - I don't know any "fast failure" benchmarks ;) After all, it will be not much longer than the regular shutdown anyway - one pass over the store. The advantage of this approach is that it follows the existing protocol and not insterts another flag (read - branch in any function working along the protocol) which leads to potential breakage. -- Stanislav Malyshev, Zend Products Engineer [EMAIL PROTECTED] http://www.zend.com/ +972-3-6139665 ext.115 -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
