Silencing the shutdown memory manager doesn't help 'my' bug, although it
probably fixes yours :)
You'd need to be on win32 to see the crash that was introduced by forcing
the DL_UNLOAD call for win32.... unless you want to 'fake it' by adding ZTS
to that 'if' list in the module_destructor.
Thanks for looking though, I know it's a pain in the neck to set up PHP-GTK
builds. Although it'd be easier to remove 'free_ts_id()' from tidy, the CG
global table problem doesn't show up there...
----- Original Message -----
From: "Dmitry Stogov" <[EMAIL PROTECTED]>
To: "'Steph Fox'" <[EMAIL PROTECTED]>
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:[EMAIL PROTECTED]
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:[EMAIL PROTECTED]
> 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
--------------------------------------------------------------------------------
--
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
