Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:23771
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Message-ID: <037f01c6834e$e1f38b00$6602a8c0@foxbox>
Reply-To: "Steph Fox" <steph@zend.com>
To: "Marcus Boerger" <helly@php.net>
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> <369893879.20060529203614@marcus-boerger.de>
Date: Mon, 29 May 2006 20:37:02 +0200
MIME-Version: 1.0
Content-Type: text/plain;
	format=flowed;
	charset="Windows-1252";
	reply-type=original
Content-Transfer-Encoding: 7bit
Subject: Re: [PHP-GTK-DEV] Re: [PHP-DEV] Ides of March [WAS:  tsrm_shutdown() and the CLI SAPI]
From: steph@zend.com ("Steph Fox")

I'm down to four possible changes - I'm just going back through them with a 
full build, one by one. (Takes ages here.)

It could be anything at present...  Dmitry, you're definitely off the hook 
over those optimizations though, promising though they seemed.

/me was hoping for something relatively obvious



> Hello Steph,
>
>  can it be that the return value of the dtor functions are wrong? They
> have always been wrong and during last months we tried to sort things
> out. Actually i was planning to have HEAD and 5.2 both respect the APPLY
> values correct. Should i wait with those changes now until someone figures
> out this dtor issue or go ahead and we look then?
>
> best regards
> marcus
>
> Monday, May 29, 2006, 11:40:15 AM, you 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
>>>
>>>
>
>
>
>
> Best regards,
> Marcus
>
> -- 
> PHP-GTK Development Mailing List (http://gtk.php.net/)
> 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
>
>