# dl() unload / module shutdown issue still unresolved

- Thread: https://externals.io/message/13539
- Original archive: https://news-web.php.net/php.internals/13539
- Started by Wez Furlong on 2004-10-26T22:13:16+00:00
- Messages: 7
- 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

---

## #13539 — Wez Furlong — 2004-10-26T22:13:16+00:00

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

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);

---

## #13541 — Rasmus Lerdorf — 2004-10-26T22:23:45+00:00

URL: https://externals.io/message/13539#13541 · In reply to: #13539

> 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

---

## #13542 — Wez Furlong — 2004-10-26T22:31:29+00:00

URL: https://externals.io/message/13539#13542 · In reply to: #13541

> 
> > […]
> 
> 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.

---

## #13543 — Rasmus Lerdorf — 2004-10-26T22:42:09+00:00

URL: https://externals.io/message/13539#13543 · In reply to: #13542

> 
> > […]
>
> 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

---

## #13544 — Wez Furlong — 2004-10-26T22:51:46+00:00

URL: https://externals.io/message/13539#13544 · In reply to: #13543

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

---

## #13545 — Shane Caraveo — 2004-10-26T23:06:00+00:00

URL: https://externals.io/message/13539#13545 · In reply to: #13541

Rasmus Lerdorf wrote:
> 
> 
> > […]
> 
> 
> 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

---

## #13546 — Rasmus Lerdorf — 2004-10-26T23:22:19+00:00

URL: https://externals.io/message/13539#13546 · In reply to: #13545

> Rasmus Lerdorf wrote:
> > […]
>
> 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