Re: tsrm_shutdown() and the CLI SAPI

php.internals

Frank M. Kromann

20 years ago
> > I'm a bit behind so sorry if this has been answered already. I don't
think
> > ts_free_id() is a workaround but it's actually correct. > > ts_free_id() would be a correct workaround if it came from
zend_shutdown().
> How's it right to suddenly force EVERY extension author to add it to
their
> code individually?
This was only reqiured in extensions registering custom dtor's like tidy and printer. - Frank

Steph

20 years ago
>> ts_free_id() would be a correct workaround if it came from > zend_shutdown(). >> How's it right to suddenly force EVERY extension author to add it to > their >> code individually? > > This was only reqiured in extensions registering custom dtor's like tidy > and printer. >
Unfortunately that's not true. It's also required in the php-gtk module even though we don't declare a dtor - the DL_UNLOAD call is the first thing in the shutdown process, and if you _don't_ have free_ts_id() in MSHUTDOWN at present you'll be freeing the resource after the module's unloaded. DL_UNLOAD is called on anything loaded via dl() or the php.ini.... This isn't our only problem though - the GLOBAL_CLASS_TABLE is being destroyed during CG dtor because it doesn't match the current CG->global_class_table. Because the CG dtor is run after the PHP-GTK module is unloaded, destroying that class table crashes the shutdown process. I've no idea why or how GTK classes end up in the CG global class table, but I guess that's what happening here. Any offers? - Steph