Hello group,
I'm looking for a way to fix http://bugs.php.net/26968. This bug is
caused by the underlying client .so using atexit() to register a cleanup
function. As the library is unloaded before process shutdown, the
atexit() stack no longer contains a valid reference when it is called,
resulting in a segfault.
IMO there are three ways to fix this:
-
Use some linker magic to redirect the call to atexit() to a wrapper
function that effectively nulls it, and call the cleanup function
ourselves in the MSHUTDOWN function. I'm not sure if this is possible,
so any help is appreciated. -
Disallow unloading of the PHP module. I'm not sure if this is a good
idea, but it seems to be the most portable solution, and the most
unintrusive, because it will only affect those who actually use the module. -
Link the main binary to the client .so instead of just the PHP module.
This will make sure that the cleanup function is present when exit() is
called, but it kind of defeats the purpose of using shared modules in
the first place.
Of course, the best solution would be to nuke the atexit() call from the
client .so, but since this problem has been around for so long, in both
Interbase and Firebird, I'm afraid it's something we will have to deal
with ourselves.
--
Ard
I don't know if we should get into this. Do we really care if we crash on
exit? We are talking about MSHUTDOWN not RSHUTDOWN here. It's not an ideal
situation but I wouldn't want screw things in PHP just for these dumb
shared libraries :)
Andi
At 02:36 PM 1/20/2004 +0100, Ard Biesheuvel wrote:
Hello group,
I'm looking for a way to fix http://bugs.php.net/26968. This bug is caused
by the underlying client .so using atexit() to register a cleanup
function. As the library is unloaded before process shutdown, the atexit()
stack no longer contains a valid reference when it is called, resulting in
a segfault.IMO there are three ways to fix this:
Use some linker magic to redirect the call to atexit() to a wrapper
function that effectively nulls it, and call the cleanup function
ourselves in the MSHUTDOWN function. I'm not sure if this is possible, so
any help is appreciated.Disallow unloading of the PHP module. I'm not sure if this is a good
idea, but it seems to be the most portable solution, and the most
unintrusive, because it will only affect those who actually use the module.Link the main binary to the client .so instead of just the PHP module.
This will make sure that the cleanup function is present when exit() is
called, but it kind of defeats the purpose of using shared modules in the
first place.Of course, the best solution would be to nuke the atexit() call from the
client .so, but since this problem has been around for so long, in both
Interbase and Firebird, I'm afraid it's something we will have to deal
with ourselves.--
Ard
I don't know if we should get into this. Do we really care if we crash
on exit?
Are you serious ?? Of course we care about segfaults, don't we, even if
it's 'only' on exit ??
We are talking about MSHUTDOWN not RSHUTDOWN here. It's not an
Depends if you use dl() or load from php.ini. If loaded by dl(), it will
segfault on every request.
ideal situation but I wouldn't want screw things in PHP just for these
dumb shared libraries :)
Actually, I've already committed a patch which will omit the dlclose()
call. This means the module will not be available if you do not dl() it
on every request, but it won't be dlclose()'d after you've loaded it
once. Note that this will only affect users who have the interbase.so
and actually use it.
--
Ard