tsrm_shutdown() and the CLI SAPI

19 years ago by Frank M. Kromann — view source

unread

tsrm_shutdown() is already comented out in the CGI version, most likely as
a fix to the same kind of problem there. Perhaps enabling that again will
show the same kind of problems?

Frank

At the moment I'm seeing it with Tidy under 5_2. Just about to get Tony
to
check.

----- Original Message -----
From: "Dmitry Stogov" dmitry@zend.com
To: "'Steph Fox'" steph@zend.com; "'Xuefer'" xuefer@gmail.com;
"'Andi
Gutmans'" andi@zend.com
Cc: "'internals'" internals@lists.php.net; "'Antony Dovgal'"
antony@zend.com
Sent: Wednesday, May 31, 2006 2:55 PM
Subject: RE: [PHP-DEV] tsrm_shutdown() and the CLI SAPI

Steph,

Commenting tsrm_shutdown() or FreeLibrary() is just hidding real
bugs.
Of course this is a solution, but not excellent.

Right now I haven't enough time even for ZE and PHP themself, so I
don't
like spent it looking into php-gtk on windows.
(I don't know GTK at all).

Do you know any other extension from PHP distribution that cause the
same
crash?
Could you provide instruction how to reproduce it?

Thanks. Dmitry.

-----Original Message-----
From: Steph Fox [mailto:steph@zend.com]
Sent: Wednesday, May 31, 2006 3:28 PM
To: Dmitry Stogov; 'Xuefer'; 'Andi Gutmans'
Cc: 'internals'; Antony Dovgal
Subject: Re: [PHP-DEV] tsrm_shutdown() and the CLI SAPI

Oh well, now I see the difference.
With my patch PHP starts call FreeLibrary() for dll extension. I
am
wonder why it wasn't called before. :)

Pure luck, by the look of it :)

Probably some other bug that is the reason of the crash was
masked by
omitting FreeLibrary(). I know Tony fixed some kind of such bugs
in
ext/tidy and ext/sybase.

Yes, he gave those extensions the ts_free_id() workaround I
mentioned a
looooooooooong time ago when I first started looking into this.

Probably php-gtk needs similar fix.

That workaround didn't work for PHP-GTK. I tried that first.
That's why I
need you to fix this bug rather than me just cover it up. The
only thing
that works for PHP-GTK is to either avoid tsrm_shutdown()
completely (via
Zeev's suggestion of commenting out the call in php_cli.c),
or to fix the
bug that makes reaching it a problem.

All other systems except win32 already used common config
file, and I
don't
see any reason for this exceptions.

I don't know or care what other systems do... how's that even
relevant?

Especially because it was the reason of bug, and masked other bugs
that
may
be reproduced on linux with ZTS.

Sorry, I didn't parse that... can you rephrase?

Thanks. Dmitry.

Cheers,

Steph

--

__________ NOD32 1.1380 (20060125) Information __________

This message was checked by NOD32 antivirus system.
http://www.eset.com

19 years ago by Steph Fox — view source

unread

Hi Frank,

tsrm_shutdown() is already comented out in the CGI version, most likely as
a fix to the same kind of problem there. Perhaps enabling that again will
show the same kind of problems?

Yes, it would, given the root cause - but would you really want to break the
whole of PHP for an academic exercise?

The more interesting thing is that none of this happens under CLI debug.
I've still no clue why.

I also think I've somehow corrupted something here with my debug lines, I'm
crashing 'differently' now <sigh />.

Steph

Frank

19 years ago by Andi Gutmans — view source

unread

At 08:23 AM 5/31/2006, Steph Fox wrote:

Hi Frank,

tsrm_shutdown() is already comented out in the CGI version, most likely as
a fix to the same kind of problem there. Perhaps enabling that again will
show the same kind of problems?

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.
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.

Andi

The more interesting thing is that none of this happens under CLI
debug. I've still no clue why.

I also think I've somehow corrupted something here with my debug
lines, I'm crashing 'differently' now <sigh />.

Steph

Frank

19 years ago by Steph Fox — view source

unread

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

19 years ago by Andi Gutmans — view source

unread

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

19 years ago by Steph Fox — view source

unread

We were hoping to release ours...

----- Original Message -----
From: "Andi Gutmans" andi@zend.com
To: "Steph Fox" steph@zend.com; "Frank M. Kromann" frank@kromann.info
Cc: "'internals'" internals@lists.php.net; "'Antony Dovgal'"
antony@zend.com; "Dmitry Stogov" dmitry@zend.com; "'Xuefer'"
xuefer@gmail.com
Sent: Thursday, June 01, 2006 8:28 AM
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

__________ NOD32 1.1380 (20060125) Information __________

This message was checked by NOD32 antivirus system.
http://www.eset.com