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

--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

-- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php



Reply via email to