solution for DL's using atexit()

php.internals

Ard Biesheuvel

22 years ago
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

Andi Gutmans

22 years ago
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:

Ard Biesheuvel

22 years ago
> 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

Andi Gutmans

22 years ago
At 12:42 PM 1/21/2004 +0100, Ard Biesheuvel wrote:
>>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 ??
What I'm saying is that if it were to require some ugly hacks in PHP to get around this problem, which besides crashing on apachectl stop and having a line in your error_log it might not be the best idea to fix it.
>>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.
dl() is evil and should be deprecated. Actually that reminds me to add an E_STRICT about it. Shared libraries should only be loaded via php.ini.

Ard Biesheuvel

22 years ago
> dl() is evil and should be deprecated. Actually that reminds me to add > an E_STRICT about it. Shared libraries should only be loaded via php.ini. >
How about setting 'enable_dl' to 'Off' in php.ini-recommended ?
-- Ard

Pierre-Alain Joye

22 years ago
On Wed, 21 Jan 2004 14:06:55 +0100 Ard Biesheuvel <ard@ard.nu> wrote:
> > dl() is evil and should be deprecated. Actually that reminds me to > > add an E_STRICT about it. Shared libraries should only be loaded via > > php.ini. > > > > How about setting 'enable_dl' to 'Off' in php.ini-recommended ?
Are you kidding? :) AFAIK and see the crash occurs only in debug mode. Why would you like to disable by default (or recommand to) disable dl? Dynamic load on extensions is a very usefull feature. I cannot imagine to live without it. pierre

Wez Furlong

22 years ago
I agree; we can't deprecate dl(). There are some very common legitimate cases where it is really useful, such as loading extensions that are not often needed into a CGI (you don't want those in php.ini as they can slow down your process startup). --Wez.

Ard Biesheuvel

22 years ago
Wez Furlong wrote:
> I agree; we can't deprecate dl(). > There are some very common legitimate cases where it is really > useful, such as loading extensions that are not often needed into > a CGI (you don't want those in php.ini as they can slow down > your process startup).
I agree, but perhaps we should make it clearer that using dl() in general is not the recommended way of using modules, because of the performance penalty and security implications. Changing the recommended setting of enable_dl is a first step.
>>AFAIK and see the crash occurs only in debug mode.
The crash that started this thread had to do with modules being unloaded, both in debug and release builds. This has already been fixed.
-- Ard

Pierre-Alain Joye

22 years ago
On Wed, 21 Jan 2004 14:52:57 +0100 Ard Biesheuvel <abies@php.net> wrote:
> Changing the recommended setting of enable_dl is a first step.
I disagree. Set enable_dl Off in the recommanded php.ini will make it disabled in many situations. This is not something good. But this discussions sounds like 'Do we have to educate endusers?'. Wez sample usage is the perfect example. And the one where I mostly use dl.
> The crash that started this thread had to do with modules being > unloaded, both in debug and release builds. This has already been > fixed.
Ilia posted about this bug weeks ago (as an explanation about my own post about that), while trying to find why pecl/date crash on exit, using debug mode, shared module(does not crash if statically linked). btw still crash here, using fresh head (linux RH9 stock install). pierre

Ard Biesheuvel

22 years ago
>>Changing the recommended setting of enable_dl is a first step. > > > I disagree. Set enable_dl Off in the recommanded php.ini will make it > disabled in many situations. This is not something good. But this > discussions sounds like 'Do we have to educate endusers?'. Wez sample > usage is the perfect example. And the one where I mostly use dl.
Why recommend anything at all if you don't want to 'educate end users' ?
>>The crash that started this thread had to do with modules being >>unloaded, both in debug and release builds. This has already been >>fixed. > > btw still crash here, using fresh head (linux RH9 stock install). >
The crash I am talking about (#26968) was indeed fixed by implementing one of the proposed changes. (I suspect you're talking about something else here)
-- Ard

Shane Caraveo

22 years ago
Why is PHP the only scripting language that has an issue with loading binary extensions at run time? :( Shane Ard Biesheuvel wrote: