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