On 9/23/05, Derick Rethans <[EMAIL PROTECTED]> 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
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
