[PATCH] 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...

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