# tsrm_shutdown() and the CLI SAPI - Thread: https://externals.io/message/23848 - Original archive: https://news-web.php.net/php.internals/23848 - Started by Dmitry Stogov on 2006-06-01T11:25:34+00:00 - Messages: 3 - 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 --- ## #23848 — Dmitry Stogov — 2006-06-01T11:25:34+00:00 URL: https://externals.io/message/23848#23848 Patch was cutted. Dmitry. > -----Original Message----- > From: Dmitry Stogov [mailto:dmitry@zend.com] > Sent: Thursday, June 01, 2006 3:05 PM > To: 'Andi Gutmans'; 'Steph Fox'; 'Frank M. Kromann' > Cc: 'internals'; 'Antony Dovgal'; 'Xuefer' > Subject: RE: [PHP-DEV] tsrm_shutdown() and the CLI SAPI > > > Hi Stepth, > > I reproduced crash of php-gtk on linix with php-zts. > I mean running "php -v" then php.ini contains > "extension=gtk2.so". The crash occurs only then php compiled > with --enable-debug. > > The reason of the crash is a bug in ZE that is activated by > memory leaks in php-gtk. In case of "php -v" we don't do > request startup/shutdown and as result we don't handle memory > leaks on request shutdown. During tsrm_shutdown() > shutdow_nmemory_manager() is called after sapi_shutdown() and > as result we cannot access sapi_globals then trying to print > information about memory leaks and crashes. > > The solution - don't print information about memory leaks > during tsrm_shutdown(). > > Patch for PHP_5_2 is attached, but it can be manually applied > to any version. > > Steph, does you crash(es) go away with this patch? > > I am going to commit patch in 24h. > Any objections? > > Thanks. Dmitry. > > > […] > really want to > > […] > understand it. > > […] > good reason > > […] > and put a > > […] > do think > > […] --- ## #23860 — Steph Fox — 2006-06-01T19:44:21+00:00 URL: https://externals.io/message/23848#23860 · In reply to: #23848 Silencing the shutdown memory manager doesn't help 'my' bug, although it probably fixes yours :) You'd need to be on win32 to see the crash that was introduced by forcing the DL_UNLOAD call for win32.... unless you want to 'fake it' by adding ZTS to that 'if' list in the module_destructor. Thanks for looking though, I know it's a pain in the neck to set up PHP-GTK builds. Although it'd be easier to remove 'free_ts_id()' from tidy, the CG global table problem doesn't show up there... ----- Original Message ----- From: "Dmitry Stogov" To: "'Steph Fox'" Cc: "'internals'" Sent: Thursday, June 01, 2006 1:25 PM Subject: RE: [PHP-DEV] tsrm_shutdown() and the CLI SAPI > Patch was cutted. > > Dmitry. > > > […] > > > __________ NOD32 1.1380 (20060125) Information __________ > > This message was checked by NOD32 antivirus system. > http://www.eset.com > > -------------------------------------------------------------------------------- > -- > > > > __________ NOD32 1.1380 (20060125) Information __________ > > This message was checked by NOD32 antivirus system. > http://www.eset.com --- ## #23862 — Steph Fox — 2006-06-02T05:46:45+00:00 URL: https://externals.io/message/23848#23862 · In reply to: #23848 Hi Dmitry, Have some diagnostics: 1) zend_shutdown() is called before anything in TSRM. It invokes zend_hash_graceful_reverse_destroy(&module_registry); 2) module_destructor() is invoked via the hash-destroyer (being part of the module_registry hash constructor). This performs the MSHUTDOWN routine for each registered module, which in several cases (now) includes a PHP-side call to ts_free_id(). The ts_free_id() call usually allows the next stage to be unproblematic; it also marks the module's entry in the resource table as 'done', so that the final clearing loop won't try to double-free it. However, ts_free_id() doesn't check for 'done' itself before it frees resources. 3) DL_UNLOAD (an alias for FreeLibrary, under doze) is then called on any module loaded via `dl()` or php.ini (checking for a module handle)... it looks like this stage might only have happened under Macs on CLI until mid-March... 4) tsrm_shutdown() - the final clearing loop - is called via the end of the various SAPI source files (in this case, php_cli.c), and any resource that hasn't been freed explicitly by this point is freed there. It won't help our particular situation, but I think automatically calling ts_free_id() on dl-loaded modules would be better than either blanket avoidance of tsrm_shutdown() or requiring each module to call ts_free_id() explicitly during MINIT. Patch(es) to do that in PHP_5_2 branch attached. The problem in PHP-GTK is we're crashing when the compiler_globals dtor is called in tsrm_shutdown(), rather than when the gtk_globals dtor is called. I think this is a ZE problem rather than ours, but see what you think: somehow, in compiler_globals_dtor(), compiler_globals->class_table != GLOBAL_CLASS_TABLE and the compiler_globals->class_table is destroyed and freed because of that. - Steph ----- Original Message ----- From: "Dmitry Stogov" To: "'Steph Fox'" Cc: "'internals'" Sent: Thursday, June 01, 2006 1:25 PM Subject: RE: [PHP-DEV] tsrm_shutdown() and the CLI SAPI > Patch was cutted. > > Dmitry. > > > […] > > > __________ NOD32 1.1380 (20060125) Information __________ > > This message was checked by NOD32 antivirus system. > http://www.eset.com > > -------------------------------------------------------------------------------- > -- > > > > __________ NOD32 1.1380 (20060125) Information __________ > > This message was checked by NOD32 antivirus system. > http://www.eset.com