Hi Dmitry,
Hm yeah that forces it to use libcmt... that'd hurt :)
Thank you for finding that! I'd looked through the debug build stuff (which
is correct) when trying to find out why PHP-GTK didn't crash at the same
point as Tidy - but I didn't check the release flags while I was there.
Still, I wouldn't say it was a waste of time - we did at least find three
other bugs through it, two of which are fixed already and one of which has
two proposed fixes waiting for evaluation. So I guess the arguments for
keeping DL_UNLOAD alive and well are proven good.
- Steph
ps Andrei - we're on for the weekend!
Hi Steph,
I finally found the reason of crash.
It has nothing related to ZE bugs.
You build php-gtk with "/MT" option.
This is completely wrong, because you use two different libc and two
different heaps.
As result when ZE calls FreeLibrary(), one of heaps is destroyed and all
pointers that were allocated from inside php-gtk.dll become inaccessible.
Rebuilding php-gtk with "/MD" fixes the problem.
Thanks. Dmitry.
-----Original Message-----
From: Steph Fox [mailto:[EMAIL PROTECTED]
Sent: Friday, June 02, 2006 10:12 PM
To: Dmitry Stogov; 'Frank M. Kromann'; Andi Gutmans
Cc: 'internals'; 'Antony Dovgal'; 'Xuefer'
Subject: Re: [PHP-DEV] tsrm_shutdown() and the CLI SAPI
Hi Andi,
>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().
Things got a bit crossed today :-\
This patch fixes a completely different bug that Dmitry came
across on his
travels.
- Steph
>
> 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
>> >
>> >
>> >
>>
>
>
> __________ 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
