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
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 = newdate(); '
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
Pierre-Alain Joye 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,
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!
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...
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