# solution for DL's using atexit()

- Thread: https://externals.io/message/7197
- Original archive: https://news-web.php.net/php.internals/7197
- Started by Ard Biesheuvel on 2004-01-20T13:36:50+00:00
- Messages: 3
- Reply by email to internals@lists.php.net
- More for agents: search with https://externals.io/search.md?q={query} · JSON API at https://externals.io/api · documentation at https://externals.io/llms.txt

---

## #7197 — Ard Biesheuvel — 2004-01-20T13:36:50+00:00

URL: https://externals.io/message/7197#7197

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

---

## #7232 — Andi Gutmans — 2004-01-21T11:35:11+00:00

URL: https://externals.io/message/7197#7232 · In reply to: #7197

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

---

## #7233 — Ard Biesheuvel — 2004-01-21T11:42:44+00:00

URL: https://externals.io/message/7197#7233 · In reply to: #7232

> 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