Hi Steph, I have no idea what is wrong with optimized class/functions tables cleanup. In case if EG(full_tables_cleanup) is set, the behavior should be exactly the same as before patch. PHP uses EG(full_table_cleanup) only for dl(), but I do't know how php-gtk uses it.
Thanks. Dmitry. > -----Original Message----- > From: Steph Fox [mailto:[EMAIL PROTECTED] > Sent: Monday, May 29, 2006 1:40 PM > To: internals > Cc: PHP-GTK dev; Dmitry Stogov > Subject: [PHP-DEV] Ides of March [WAS: tsrm_shutdown() and > the CLI SAPI] > > > Hi all, > > I've spent a fun weekend debugging TSRM and bits of ZE2, > having finally > figured that the zend_compiler_globals dtor was the point of > failure here. > > TSRM needs to mark resources as 'done' following a free and > doesn't in most > cases, but that's actually not the main problem we have in > PHP-GTK (although > fixing it may well solve everybody else's, I'll check that on > my travels). > > Dmitry's "Optimized cleanup loops on request shutdown" > commit(s) spanning > the 13th and 14th March broke Andrei's > 'EG(full_tables_cleanup) = 1' ruse > (we needed user classes to be cleaned and internal classes to > stay), but it > also broke TSRM shutdown completely for us. PHP-GTK classes > are recognized > as being internal, but only the first one ever reaches the > dtor - even when > there are no user-defined classes. > > zend_hash_reverse_apply() is called at that point, so I'm > guessing there's a > reentrancy issue behind my access violation crash. > > I'll get back to this when I get some time, in the meantime if anyone > (Dmitry?) wants to play with this you need to know that I > can't put the 5_2 > compat stuff into CVS until Andrei OKs it, so PHP-GTK HEAD > has to be built > against PHP_5_1 branch at present (anything after March 14th will do). > > - Steph > > > > Under CLI ZTS build, when loading a PHP-GTK 2 .dll built against > > anything > > this side of PHP 5.1.2 release, I'm seeing an 'access > violation' crash on > > reaching: > > > > if (resource_types_table && !resource_types_table[j].done && > > resource_types_table[j].dtor) { > > resource_types_table[j].dtor(p->storage[j], &p->storage); > > } > > > > Similar code is also used in: > > > > tsrm_free_interpreter_context() > > ts_free_thread() > > ts_free_worker_threads() > > ts_free_id() > > > > I thought ts_free_thread() was crashing at that line too at > first, but > > that turned out to be because there's no 'done' check > there, i.e. double > > dtors are possible via some functions. It's still vaguely > possible there's > > a double flypast causing the crash I'm seeing, but I have > everything I > > know about protected now. (On my laptop that is.) > > > > Eventually I found the resource id for PHP-GTK - the only extension > > I'm > > loading during runtime, via php.ini - is 32nd out of a possible 32. > > "Eventually", because that means I can't use ts_free_id() > to avoid the > > crash as advised by Frank (and Tony, and Dmitry, and anyone > else who ever > > used that MSHUTDOWN workaround for CLI). Interesting too, > because the > > resource that causes the crash appears to be something > completely other. > > Tracking down resource id #5 - and that's all I know about > it apart from > > it crashes - is a barrel of laughs, I'll let y'all know if > I ever find out > > which of the many possible extensions/files in ext/standard > or core it is. > > > > Short version: One line is problematic, and only in one > function, and > > presumably only under CLI SAPI. (CGI already doesn't call > tsrm_shutdown(), > > thanks to similar issues some 3 years ago). > > > > The question is whether to take 'the Zeev approach' and > simply comment > > out > > the tsrm_shutdown() call at the end of sapi/cli/php_cli.c, > or whether to > > spend time knitting up a fine-grained approach to prevent > the one bad line > > in the function from being called in single-threaded > environments? I think > > I've given up on the idea of actually resolving the bug now... > > > > Thoughts? > > > > - oh, and don't make one of them 'chicken-and-egg' - this is > > definitively > > NOT related to the shutdown order in main.c!!!!! > > > > - Steph > > > > -- > > PHP Internals - PHP Runtime Development Mailing List > > To unsubscribe, visit: http://www.php.net/unsub.php > > > > > > __________ NOD32 1.1380 (20060125) Information __________ > > > > This message was checked by NOD32 antivirus system. > > http://www.eset.com > > > > > > -- > PHP Internals - PHP Runtime Development Mailing List > To unsubscribe, visit: http://www.php.net/unsub.php > > > -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
