Newsgroups: php.gtk.dev,php.internals
Path: news.php.net
Xref: news.php.net php.gtk.dev:2909 php.internals:23766
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Message-ID: <447AD04B.2030507@emini.dk>
Date: Mon, 29 May 2006 12:43:23 +0200
Organization: Emini A/S
User-Agent: Mozilla Thunderbird 1.0.6 (Windows/20050716)
MIME-Version: 1.0
To: Steph Fox <steph@zend.com>
Cc: internals <internals@lists.php.net>,
	PHP-GTK dev <php-gtk-dev@lists.php.net>,
	Dmitry Stogov <dmitry@zend.com>
References: <11b601c681bd$c1fc3050$6602a8c0@foxbox> <010c01c68303$e4fe2800$6602a8c0@foxbox>
In-Reply-To: <010c01c68303$e4fe2800$6602a8c0@foxbox>
OpenPGP: id=157D0FA8
Content-Type: text/plain; charset=windows-1252
Content-Transfer-Encoding: 7bit
Subject: Re: [PHP-DEV] Ides of March [WAS:  tsrm_shutdown() and the CLI SAPI]
From: edink@emini.dk (Edin Kadribasic)

Hi,

Yes, something broke while we were at 5.1.3-dev.

It would be really nice if Dmitry could have a look at this. We have
many reports that things have gotten much more ustable on Windows since
5.1.2.

Edin


Steph Fox wrote:
> 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
>>
>>
>