Just noticed that I still have a pending commit:
Can someone more familiar with the load order figure out what happened
to break this?
The problem is that when you dl(), PHP segfaults during shutdown for
any dl()'d extension that creates objects and where the script has
globals referencing them.
It should be safe to never ever dlclose() a module.
--Wez.
Index: Zend/zend_API.c
RCS file: /repository/ZendEngine2/zend_API.c,v
retrieving revision 1.268
diff -u -p -r1.268 zend_API.c
--- Zend/zend_API.c 29 Sep 2004 20:57:07 -0000 1.268
+++ Zend/zend_API.c 26 Oct 2004 22:01:23 -0000
@@ -1520,7 +1520,7 @@ void module_destructor(zend_module_entry
zend_unregister_functions(module->functions, -1, NULL
TSRMLS_CC);
}
-#if HAVE_LIBDL
+#if HAVE_LIBDL && 0
#if !(defined(NETWARE) && defined(APACHE_1_BUILD))
if (module->handle) {
dlclose(module->handle);
It should be safe to never ever dlclose() a module.
Do you mean never to dlclose() a module loaded via dl() at request time or
do you mean that in general it should be safe to never dlclose() a module
even if it came in via an extension line in the php.ini file? The former
is likely a true statement, but the latter is definitely not.
-Rasmus
It should be safe to never ever dlclose() a module.
Do you mean never to dlclose() a module loaded via
dl()at request time or
do you mean that in general it should be safe to never dlclose() a module
even if it came in via an extension line in the php.ini file? The former
is likely a true statement, but the latter is definitely not.
I did mean the latter. What's the issue there?
--Wez.
It should be safe to never ever dlclose() a module.
Do you mean never to dlclose() a module loaded via
dl()at request time or
do you mean that in general it should be safe to never dlclose() a module
even if it came in via an extension line in the php.ini file? The former
is likely a true statement, but the latter is definitely not.I did mean the latter. What's the issue there?
It's a bit tricky. When Apache starts up it does a double-pass of the
conf files in order to do a syntax check. It needs to load all its
modules in order to do this so our libphp4.so gets loaded which in turn
causes us to load all our extensions. Then Apache unloads libphp4.so and
starts over and reloads libphp4.so. Now, in between these two dlopens of
libphp4.so memory usage can change dramatically. For example, if you have
a bunch of mod_rewrite rules in your Apache conf the second time
libphp4.so is loaded it can easily be a page higher in memory. If the
extensions that PHP loaded on the first pass were not unloaded then any
callback addresses in the extensions are going to be off by a page and you
will get some very nasty crashes.
-Rasmus
Urgh.
It's a bit tricky. When Apache starts up it does a double-pass of the
conf files in order to do a syntax check. It needs to load all its
modules in order to do this so our libphp4.so gets loaded which in turn
causes us to load all our extensions. Then Apache unloads libphp4.so and
starts over and reloads libphp4.so. Now, in between these two dlopens of
libphp4.so memory usage can change dramatically. For example, if you have
a bunch of mod_rewrite rules in your Apache conf the second time
libphp4.so is loaded it can easily be a page higher in memory. If the
extensions that PHP loaded on the first pass were not unloaded then any
callback addresses in the extensions are going to be off by a page and you
will get some very nasty crashes.-Rasmus
Rasmus Lerdorf wrote:
It should be safe to never ever dlclose() a module.
Do you mean never to dlclose() a module loaded via
dl()at request time or
do you mean that in general it should be safe to never dlclose() a module
even if it came in via an extension line in the php.ini file? The former
is likely a true statement, but the latter is definitely not.-Rasmus
It's exactly how other languages deal with binary extensions, once
loaded, never unload, even between requests. That approach would fix
and greatly simplify dl for php (note I haven't looked at dl code in
more than a year so I could be speaking out of my ass). The double pass
that Apache could be handled by having php_apache avoid processing
extensions on the first pass.
Shane
Rasmus Lerdorf wrote:
It should be safe to never ever dlclose() a module.
Do you mean never to dlclose() a module loaded via
dl()at request time or
do you mean that in general it should be safe to never dlclose() a module
even if it came in via an extension line in the php.ini file? The former
is likely a true statement, but the latter is definitely not.-Rasmus
It's exactly how other languages deal with binary extensions, once
loaded, never unload, even between requests. That approach would fix
and greatly simplify dl for php (note I haven't looked at dl code in
more than a year so I could be speaking out of my ass). The double pass
that Apache could be handled by having php_apache avoid processing
extensions on the first pass.
Then we would potentially be throwing bogus syntax errors since the
extension handling a particular conf directive embedded in an Apache conf
file wouldn't be there.
-Rasmus