This patch fixes very specific bug.

"php -v" calls RINIT() functions, php with php-gtk throws error from RINIT
if we run php from telent/ssh session, because it cannot open DISPLAY. As
result we don't go into request shutdown (shutdown_memory_manager() is
called there) sequence and doing module shutdown and tsrm_shutdown(). 
Because request_shutdown() wasn't done we didn't cleared emalloced memory,
and trying to do it during tsrm_shutdown() but some globals (sapi globals)
are destroyed in this time. As result we get a crash.

Thanks. Dmitry.

> -----Original Message-----
> From: Andi Gutmans [mailto:[EMAIL PROTECTED] 
> Sent: Friday, June 02, 2006 10:08 PM
> To: Dmitry Stogov; 'Steph Fox'; 'Frank M. Kromann'
> Cc: 'internals'; 'Antony Dovgal'; 'Xuefer'
> Subject: RE: [PHP-DEV] tsrm_shutdown() and the CLI SAPI
> 
> 
> I don't understand this patch. Doesn't this completely remove 
> printing memory leaks? We never fixed this bug but as it was only 
> relevant to the debug version and dl() we were OK with it... Of 
> course there's also the option of not calling DL_UNLOAD().
> 
> Andi
> 
> At 04:05 AM 6/1/2006, Dmitry Stogov wrote:
> >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
> > >
> > >
> > >
> >
> 
> 
> 

-- 
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

Reply via email to