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

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:

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.

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