# ZE2, dl() and objects

- Thread: https://externals.io/message/6917
- Original archive: https://news-web.php.net/php.internals/6917
- Started by Ilia Alshanetsky on 2004-01-09T05:11:44+00:00
- Messages: 5
- 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

---

## #6917 — Ilia Alshanetsky — 2004-01-09T05:11:44+00:00

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

It seems there is a problem in either the PHP's shutdown sequence in  
php_request_shutdown() or destrutor order in ZE2. The problem is quite 
simple, the module loaded via `dl()` (when libdl is used) is unloaded before 
the objects it creates are destroyed. Consequently when Zend Engine tries to 
destroy the object the handler pointer is pointing to a random memory 
address.

This can only be replicate if libdl is used because the module unloading is 
conditional upon HAVE_LIBDL inside module_destructor().

To demonstrate the problem compile pecl/date as a shared module and run
-r ' dl("date.so"); $a = new `date()`; '

Ilia

---

## #6925 — Pierre-Alain Joye — 2004-01-09T11:03:18+00:00

URL: https://externals.io/message/6917#6925 · In reply to: #6917

On Fri, 9 Jan 2004 00:11:44 -0500
Ilia Alshanetsky <ilia@prohost.org> wrote:

> It seems there is a problem in either the PHP's shutdown sequence in  
> php_request_shutdown() or destrutor order in ZE2. The problem is quite
> simple,

Thanks to point it out :-) Simple but difficult to figure out what
happens :).

> To demonstrate the problem compile pecl/date as a shared module and
> run-r ' dl("date.so"); $a = new `date()`; '

I do not know if that can help but adding $a=null; obviously do not
crash.

Am I the only one to get such problem within an extension? That makes
hard to track down the leaks or things like that (in debug mode).

pierre

---

## #7150 — Martin Eisengardt — 2004-01-17T14:28:01+00:00

URL: https://externals.io/message/6917#7150 · In reply to: #6925

Pierre-Alain Joye wrote:

> > […]
I did some debugging and got a segfault in zend_variables.c:61
        ZEND_OBJ_HT_P(zvalue)->del_ref(zavlue TSRMLS_CC);

seems that the class definitions an extension defines are lost (the
extension is unloaded) before the created variables are destroyed.
object_handlers table is destroyed. If you set your object
to null inside php script or if you destroy all public variables
inside module shutdown sequence it works fine...

        $a=null;
works fine.

code block from php_request_shutdown() (main.c:1216)

        if (PG(modules_activated)) {
                zend_deactivate_modules(TSRMLS_C);   // modules are unloaded
        }
[...]
        zend_deactivate(TSRMLS_C); // variables are destroyed inside here

If you change the order it works and there are no segfaults. but there are
some other problems php reports:

/home/mepeisen/projects/php/php-5.0.0b3/Zend/zend_hash.c(672) : ht=0x8230ef8
is already destroyed
/home/mepeisen/projects/php/php-5.0.0b3/Zend/zend_hash.c(672) : ht=0x8230ef8
is already destroyed
/home/mepeisen/projects/php/php-5.0.0b3/Zend/zend_hash.c(67) : Bailed out
without a bailout address!

---

## #7164 — Cristiano Duarte — 2004-01-17T21:24:00+00:00

URL: https://externals.io/message/6917#7164 · In reply to: #6925

> I do not know if that can help but adding $a=null; obviously do not
> crash.
> 
> Am I the only one to get such problem within an extension? That makes
> hard to track down the leaks or things like that (in debug mode).
No Pierre. I'm experiencing the same problem with my PHP5 CORBA
extension.

Cristiano Duarte

---

## #7206 — Martin Eisengardt — 2004-01-20T22:41:17+00:00

URL: https://externals.io/message/6917#7206 · In reply to: #7150

The bug is postet at #26945.

I created some sample extensions and scripts to reproduce segfaults. They
create some nice debugging output. One could ask me to get the sources.
Please use this bug as subject of your email to not get into my spam
filter ;-)
I hope this bug will be fixed soon.

By the way:
Compiling php and extensions with debugging (./configure --enable-debug)
create some other segfaults at the end of scripts when creating memory
leaks. I do not know whether this only touches dynamical loaded extensions
(function dl). This nice bug is based on shutdown order too.
Since it does not touch productive releases (they should be compiled without
--enable-debug) it isn't that important. But nice to know for developers...