Re: 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:steph@zend.com] 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