Hi Steph, As I remember this patch modified "zend_config.w32.h". It made inclusion of "main/config.w32.h" in the same way as on all other systems. How it affects TSRM? May be I forgot something.
Thanks. Dmitry. > -----Original Message----- > From: Steph Fox [mailto:[EMAIL PROTECTED] > Sent: Tuesday, May 30, 2006 1:30 AM > To: Dmitry Stogov > Cc: 'PHP-GTK dev'; 'internals' > Subject: Re: [PHP-DEV] Ides of March [WAS: tsrm_shutdown() > and the CLI SAPI] > > > Hi Dmitry, > > Finally cracked it, and you're right it had nothing to do > with the suspected > optimizations. There was a win32 memory fix where you > included the PHP win32 > config file in the Zend one, confusing heck out of TSRM's totally > independent (until it meets Zend) alloca definition, which is > some way > before Zend meets PHP's. They all need to match. > > Can you find some other way to fix #36568 pliz? > > I'll take another look at those flags in TSRM itself for the > work-aroundable > shutdown issues when I've caught up with the weeklies... > > - Steph > > ps I knew it had to be you - nobody else did anything major > in core that > week ;) > > > > > 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 > > > > > > __________ 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
