# shutdown order changed again? broken dl()'d modules, again

- Thread: https://externals.io/message/19133
- Original archive: https://news-web.php.net/php.internals/19133
- Started by Wez Furlong on 2005-09-23T02:27:29+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

---

## #19133 — Wez Furlong — 2005-09-23T02:27:29+00:00

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

I'm getting this on shutdown with PHP 5.1 when using persistent
connections with a dl'd PDO.
Dan mentioned something similar with the ibm_db2 extension:

==23982==
==23982== Jump to the invalid address stated on the next line
==23982==    at 0x1BCE5C0B: ???
==23982==    by 0x81BB4BC: zend_hash_apply_deleter (zend_hash.c:574)
==23982==    by 0x81BB665: zend_hash_graceful_reverse_destroy (zend_hash.c:640)
==23982==    by 0x81BD680: zend_destroy_rsrc_list (zend_list.c:240)
==23982==  Address 0x1BCE5C0B is not stack'd, malloc'd or (recently) free'd
==23982==
==23982== Process terminating with default action of signal 11 (SIGSEGV)
==23982==  Access not within mapped region at address 0x1BCE5C0B
==23982==    at 0x1BCE5C0B: ???
==23982==    by 0x81BB4BC: zend_hash_apply_deleter (zend_hash.c:574)
==23982==    by 0x81BB665: zend_hash_graceful_reverse_destroy (zend_hash.c:640)
==23982==    by 0x81BD680: zend_destroy_rsrc_list (zend_list.c:240)

Sounds like we're unloading the modules before calling the dtors again.

--Wez.

---

## #19134 — Andi Gutmans — 2005-09-23T03:15:11+00:00

URL: https://externals.io/message/19133#19134 · In reply to: #19133

Yep, we reverted to the previous state because we broke stuff. The 
real solution is to have a two phase shutdown.
Is your script just for testing? (it's weird to have a persistent 
connection with a `dl()`, but that doesn't mean we shouldn't introduce 
another shutdown stage.)

At 07:27 PM 9/22/2005, Wez Furlong wrote:
>I'm getting this on shutdown with PHP 5.1 when using persistent
>connections with a dl'd PDO.
>Dan mentioned something similar with the ibm_db2 extension:
>
>==23982==
>==23982== Jump to the invalid address stated on the next line
>==23982==    at 0x1BCE5C0B: ???
>==23982==    by 0x81BB4BC: zend_hash_apply_deleter (zend_hash.c:574)
>==23982==    by 0x81BB665: zend_hash_graceful_reverse_destroy 
>(zend_hash.c:640)
>==23982==    by 0x81BD680: zend_destroy_rsrc_list (zend_list.c:240)
>==23982==  Address 0x1BCE5C0B is not stack'd, malloc'd or (recently) free'd
>==23982==
>==23982== Process terminating with default action of signal 11 (SIGSEGV)
>==23982==  Access not within mapped region at address 0x1BCE5C0B
>==23982==    at 0x1BCE5C0B: ???
>==23982==    by 0x81BB4BC: zend_hash_apply_deleter (zend_hash.c:574)
>==23982==    by 0x81BB665: zend_hash_graceful_reverse_destroy 
>(zend_hash.c:640)
>==23982==    by 0x81BD680: zend_destroy_rsrc_list (zend_list.c:240)
>
>Sounds like we're unloading the modules before calling the dtors again.
>
>--Wez.

---

## #19135 — Wez Furlong — 2005-09-23T03:29:09+00:00

URL: https://externals.io/message/19133#19135 · In reply to: #19134

Actually, it's using php.ini to load pdo for the CLI, and not calling `dl()`.

The script is just a test script, but this is still a PHP level bug
that we should, IMO,  fix before 5.1.

--Wez.


> Yep, we reverted to the previous state because we broke stuff. The
> real solution is to have a two phase shutdown.
> Is your script just for testing? (it's weird to have a persistent
> connection with a `dl()`, but that doesn't mean we shouldn't introduce
> another shutdown stage.)
>
> At 07:27 PM 9/22/2005, Wez Furlong wrote:
> > […]

---

## #19140 — Derick Rethans — 2005-09-23T07:19:35+00:00

URL: https://externals.io/message/19133#19140 · In reply to: #19133

> Sounds like we're unloading the modules before calling the dtors again.

The code says this:
    /* 1. Call all possible shutdown functions registered with `register_shutdown_function()` */
    /* 2. Call all possible __destruct() functions */
    zend_try {
        zend_call_destructors(TSRMLS_C);
    } zend_end_try();

    /* 3. Flush all output buffers */
    /* 4. Send the set HTTP headers (note: This must be done AFTER 
    /* 5. Call all extensions RSHUTDOWN functions */
    if (PG(modules_activated)) {
        zend_deactivate_modules(TSRMLS_C);
        php_free_shutdown_functions(TSRMLS_C);
    }

So your statement seems incorrect, not sure what is breaking though...

regards,
Derick

-- 
Derick Rethans
http://derickrethans.nl | http://ez.no | http://xdebug.org

---

## #19147 — Dan Scott — 2005-09-24T11:01:06+00:00

URL: https://externals.io/message/19133#19147 · In reply to: #19140

> 
>
> > […]
>
> The code says this:
>     /* 1. Call all possible shutdown functions registered with `register_shutdown_function()` */
>     /* 2. Call all possible __destruct() functions */
>     zend_try {
>         zend_call_destructors(TSRMLS_C);
>     } zend_end_try();
>
>     /* 3. Flush all output buffers */
>     /* 4. Send the set HTTP headers (note: This must be done AFTER
>     /* 5. Call all extensions RSHUTDOWN functions */
>     if (PG(modules_activated)) {
>         zend_deactivate_modules(TSRMLS_C);
>         php_free_shutdown_functions(TSRMLS_C);
>     }
>
> So your statement seems incorrect, not sure what is breaking though...

I don't think the bug I'm seeing is related to any change in the PHP
shutdown order -- on RHEL 4 and Gentoo the ibm_db2 extension segfaults
on shutdown when compiled as a shared extension and run in CLI mode,
no matter whether I'm using PHP 5.0.3, 5.0.4, 5.0.5, or HEAD.
Compiling it statically, however, prevents the shutdown segfault from
occurring.

This problem did not happen in the past on these distros, so I suspect
that it's actually a recent update to glibc/libstdc++/ld that's
causing the segfault strace shows libstdc++ getting mmap'ed before
libgcc_s, and then getting munmap'ed before libgcc_s. (libdb2 is
compiled from C++, thus the dependency on libstdc++.)

Based on past experiences with FreeBSD 4.6, Andrei and Rasmus
suggested that the problem may be a defective linker, which seems
entirely plausible. I'll try compiling PDO + PDO_ODBC (ibm-db2
flavour) as a shared extension to see if it suffers the same fate.

Dan

---

## #19148 — Wez Furlong — 2005-09-24T13:53:45+00:00

URL: https://externals.io/message/19133#19148 · In reply to: #19147

Curious; I haven't updated glibc or libstdc++ on my system, and I
didn't get this problem a few weeks back.

--Wez.


> This problem did not happen in the past on these distros, so I suspect
> that it's actually a recent update to glibc/libstdc++/ld that's
> causing the segfault strace shows libstdc++ getting mmap'ed before
> libgcc_s, and then getting munmap'ed before libgcc_s. (libdb2 is
> compiled from C++, thus the dependency on libstdc++.)
>
> Based on past experiences with FreeBSD 4.6, Andrei and Rasmus
> suggested that the problem may be a defective linker, which seems
> entirely plausible. I'll try compiling PDO + PDO_ODBC (ibm-db2
> flavour) as a shared extension to see if it suffers the same fate.

---

## #19307 — Dan Scott — 2005-09-30T15:33:50+00:00

URL: https://externals.io/message/19133#19307 · In reply to: #19148

PDO_ODBC from CVS didn't seem to want to compile with PHP5.0.5, so I
tried Unified ODBC instead.

On the bright(?) side, I'm seeing the same segfault problem with
Unified ODBC compiled against the DB2 libraries as a shared module. So
it doesn't seem to be a problem with the code of the extensions
themselves (that, or we've managed to make a mistake in ibm_db2 that
matches an ext/odbc mistake).

Dan


> Curious; I haven't updated glibc or libstdc++ on my system, and I
> didn't get this problem a few weeks back.
>
> --Wez.
>
> 
> > […]