Everything
php
Learn Community Releases The PHP Project
Home » Project » Newsgroups » php.internals » shutdown order changed again? broken dl()'d modules, again »

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

php.internals

Wez Furlong

20 years ago
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.

Andi Gutmans

20 years ago
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:

Wez Furlong

20 years ago
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. On 9/22/05, Andi Gutmans <andi@zend.com> wrote:

Derick Rethans

20 years ago
On Thu, 22 Sep 2005, Wez Furlong wrote:
> 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

Dan Scott

20 years ago
On 9/23/05, Derick Rethans <derick@php.net> wrote:
> On Thu, 22 Sep 2005, Wez Furlong wrote: > > > 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...
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

Wez Furlong

20 years ago
Curious; I haven't updated glibc or libstdc++ on my system, and I didn't get this problem a few weeks back. --Wez. On 9/24/05, Dan Scott <denials@gmail.com> wrote:

Dan Scott

20 years ago
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 On 9/24/05, Wez Furlong <kingwez@gmail.com> wrote: