# Fw:  More diagnostics - win32/shared extension shutdown crash [WAS: the most bizarre thing...]

- Thread: https://externals.io/message/23904
- Original archive: https://news-web.php.net/php.internals/23904
- Started by Steph Fox on 2006-06-04T03:06:50+00:00
- Messages: 1
- Reply by email to internals@lists.php.net
- More for agents: search with https://externals.io/search.md?q={query} · JSON API at https://externals.io/api · documentation at https://externals.io/llms.txt

---

## #23904 — Steph Fox — 2006-06-04T03:06:50+00:00

URL: https://externals.io/message/23904#23904

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 may 
> be
>         * 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...
>
>
> > […]