Hi Dmitry,
Have some diagnostics:
1) zend_shutdown() is called before anything in TSRM. It invokes
zend_hash_graceful_reverse_destroy(&module_registry);
2) module_destructor() is invoked via the hash-destroyer (being part of the
module_registry hash constructor). This performs the MSHUTDOWN routine for
each registered module, which in several cases (now) includes a PHP-side
call to ts_free_id(). The ts_free_id() call usually allows the next stage to
be unproblematic; it also marks the module's entry in the resource table as
'done', so that the final clearing loop won't try to double-free it.
However, ts_free_id() doesn't check for 'done' itself before it frees
resources.
3) DL_UNLOAD (an alias for FreeLibrary, under doze) is then called on any
module loaded via dl() or php.ini (checking for a module handle)... it looks
like this stage might only have happened under Macs on CLI until
mid-March...
4) tsrm_shutdown() - the final clearing loop - is called via the end of the
various SAPI source files (in this case, php_cli.c), and any resource that
hasn't been freed explicitly by this point is freed there.
It won't help our particular situation, but I think automatically calling
ts_free_id() on dl-loaded modules would be better than either blanket
avoidance of tsrm_shutdown() or requiring each module to call ts_free_id()
explicitly during MINIT. Patch(es) to do that in PHP_5_2 branch attached.
The problem in PHP-GTK is we're crashing when the compiler_globals dtor is
called in tsrm_shutdown(), rather than when the gtk_globals dtor is called.
I think this is a ZE problem rather than ours, but see what you think:
somehow, in compiler_globals_dtor(),
compiler_globals->class_table != GLOBAL_CLASS_TABLE
and the compiler_globals->class_table is destroyed and freed because of
that.
- Steph
----- Original Message -----
From: "Dmitry Stogov" <dmitry@zend.com>
To: "'Steph Fox'" <steph@zend.com>
Cc: "'internals'" <internals@lists.php.net>
Sent: Thursday, June 01, 2006 1:25 PM
Subject: RE: [PHP-DEV] tsrm_shutdown() and the CLI SAPI
> Patch was cutted.
>
> Dmitry.
>
>> -----Original Message-----
>> From: Dmitry Stogov [mailto:dmitry@zend.com]
>> Sent: Thursday, June 01, 2006 3:05 PM
>> To: 'Andi Gutmans'; 'Steph Fox'; 'Frank M. Kromann'
>> Cc: 'internals'; 'Antony Dovgal'; 'Xuefer'
>> Subject: RE: [PHP-DEV] tsrm_shutdown() and the CLI SAPI
>>
>>
>> Hi Stepth,
>>
>> I reproduced crash of php-gtk on linix with php-zts.
>> I mean running "php -v" then php.ini contains
>> "extension=gtk2.so". The crash occurs only then php compiled
>> with --enable-debug.
>>
>> The reason of the crash is a bug in ZE that is activated by
>> memory leaks in php-gtk. In case of "php -v" we don't do
>> request startup/shutdown and as result we don't handle memory
>> leaks on request shutdown. During tsrm_shutdown()
>> shutdow_nmemory_manager() is called after sapi_shutdown() and
>> as result we cannot access sapi_globals then trying to print
>> information about memory leaks and crashes.
>>
>> The solution - don't print information about memory leaks
>> during tsrm_shutdown().
>>
>> Patch for PHP_5_2 is attached, but it can be manually applied
>> to any version.
>>
>> Steph, does you crash(es) go away with this patch?
>>
>> I am going to commit patch in 24h.
>> Any objections?
>>
>> Thanks. Dmitry.
>>
>> > -----Original Message-----
>> > From: Andi Gutmans [mailto:andi@zend.com]
>> > Sent: Thursday, June 01, 2006 10:29 AM
>> > To: Steph Fox; Frank M. Kromann
>> > Cc: 'internals'; 'Antony Dovgal'; Dmitry Stogov; 'Xuefer'
>> > Subject: Re: [PHP-DEV] tsrm_shutdown() and the CLI SAPI
>> >
>> >
>> > As we are not planning to release a new version within the next
>> > couple of weeks, I suggest before jumping to conclusions we
>> > take a look at it.
>> >
>> > If you really need to comment out that line in the meanwhile
>> > that's OK with me.
>> >
>> > Andi
>> >
>> > At 09:50 PM 5/31/2006, Steph Fox wrote:
>> > >>>Yes, it would, given the root cause - but would you
>> really want to
>> > >>>break the whole of PHP for an academic exercise?
>> > >>
>> > >>It's not really an academic exercise. If we know there's a bug
>> > >>someplace we should at least look into it and try and
>> understand it.
>> > >
>> > >Frank's referring to Zeev's three-years-ago decision to simply opt
>> > >out of tsrm_shutdown() here... he's suggesting we revert it.
>> > >
>> > >>Then if we decide to remove the trsm_shutdown call for a
>> good reason
>> > >>(circular dependency, blah blah blah) then we can do that
>> and put a
>> > >>nice fat comment on why it's the right thing to do. But I
>> do think
>> > >>it's benefical to try and understand what's happening.
>> > >
>> > >Fine, but breaking working code while you're trying to understand
>> > >what's happening is far from beneficial to our users. Can't
>> > we at least #0 it?
>> > >
>> > >>
>> > >>Andi
>> >
>> > --
>> > 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
>
>
--------------------------------------------------------------------------------
