erm, with attached output!
----- Original Message -----
From: "Steph Fox" steph@zend.com
To: "Dmitry Stogov" dmitry@zend.com; "Andi Gutmans" andi@zend.com
Cc: "internals" internals@lists.php.net
Sent: Sunday, June 04, 2006 5:02 AM
Subject: [PHP-DEV] More diagnostics - win32/shared extension shutdown crash
[WAS: the most bizarre thing...]
OK people, I'm finally getting somewhere with this one now. More
diagnostics:In debug mode, the Tidy extension crashes with an assert failure at
exactly the same point PHP-GTK release version dies - during the call to
zend_hash_destroy(compiler_globals->class_table) from
compiler_globals_dtor(), the second time the dtor's called.By this time GLOBALS_CLASS_TABLE no longer exists, which is why my
original patch for this works. (That table does exist the first time
compiler_globals_dtor() is called, and I wasn't able to 'watch' the dtor
being called during shutdown until now.)That assert failure comes from dbgheap.c:
/* * If this ASSERT fails, a bad pointer has been passed in. It maybe
* totally bogus, or it may have been allocated from another heap.
* The pointer MUST come from the 'local' heap.
*/
_ASSERTE(_CrtIsValidHeapPointer(pUserData));Running Tidy in release mode with a few of my own debugging lines gives
the attached output. See where that single call to
zend_hash_destroy(compiler_globals->class_table) triggers 330 further
calls to zend_hash_destroy() for Tidy? It gets through 307 of a potential
1446 calls before crashing there for PHP-GTK. That 307 happens to be the
exact same number it gets through for Tidy in debug mode before the assert
failure. I'd guess 307 debug lines is as much as my console can print
between loading the CG class table into zend_hash_destroy and actually
crashing :)It's quite likely I've got some win32 debug flags mixed up somewhere in
the PHP-GTK build system - I'm getting the same results for 'release'
PHP-GTK as for 'debug' Tidy, except of course without the helpful message.
But the underlying problem looks like being that we pass an invalid
pointer to zend_hash_destroy() from the compiler globals destructor during
shutdown, when any shared extension declaring its own internal classes
is loaded.The same isn't true regarding internal functions...
Can anyone back this 'true-on-my-box' theory? - I only have two extensions
handy to test this with at present.You're looking for a crash on shutdown under CLI win32 debug, for
ini-loaded extensions declaring their own classes. Currently those
extensions also need to have "ts_free_id(extname#_globals_id);" in their
MSHUTDOWN function, or you'll see the wrong crash.
- Steph
----- Original Message -----
From: "Steph Fox" steph@zend.com
To: "Dmitry Stogov" dmitry@zend.com
Cc: "internals" internals@lists.php.net
Sent: Friday, June 02, 2006 8:41 AM
Subject: [PHP-DEV] [PATCH] the most bizarre thing...Dmitry, have you any idea why this might fix my CG table-freeing crash?
It still gets past the != check, so presumably it still does the same
destroy-and-free - but it works now?!
- Steph