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
