OK, knowing exactly what is going on when there are lots of other
peoples code involved (a framework, ADODB, JPSpan, etc.) is tuff, but
here is what I think:
The lowdown: mysqli seems to be gone by the time the shutdown function
is called (the error being "Couldn't fetch mysqli"). That makes an
exception, and depending on whatever else is loaded, it will either
try to squelch the error or throw a new exception which leads to the
error at Unknown at line 0 bug.
At any rate, there are two problems:
-
That the newly thrown exception blows up into a fatal error that
doesn't list the file or line number. -
mysqli is unloaded(!?) (or appears to be) before the the user's
shutdown function is called. This one is SERIOUS -- I use it to save
session data, etc. This then becomes impossible to do.
In the backtrace you'll notice that the function table (in fact, all
parameters, are, as Markus says, borked!) when going from
call_user_function() to call_user_function_ex() on the mysqli
extention.
#24 0x0823e95c in call_user_function_ex (function_table=0x1,
object_pp=0x1, function_name=0x1, retval_ptr_ptr=0x1, param_count=1,
params=0x1, no_separation=1, symbol_table=0x1)
at /php-5.1.0RC1/Zend/zend_execute_API.c:571
#25 0x0823e998 in call_user_function (function_table=0xa0a2350,
object_pp=0x0, function_name=0xa43f80c, retval_ptr=0xbfe96ad0,
param_count=0, params=0xa448280)
at /php-5.1.0RC1/Zend/zend_execute_API.c:544
I guess I should make a bug report or two. ??
-steve
At any rate, there are two problems:
- That the newly thrown exception blows up into a fatal error that
doesn't list the file or line number.
Example code?
- mysqli is unloaded(!?) (or appears to be) before the the user's
shutdown function is called. This one is SERIOUS -- I use it to save
session data, etc. This then becomes impossible to do.
__destruct()'s are called before the user registered shutdown functions.
This will not change so don't bother reporting a bug about this.
In the backtrace you'll notice that the function table (in fact, all
parameters, are, as Markus says, borked!) when going from
call_user_function() to call_user_function_ex() on the mysqli
extention.#24 0x0823e95c in call_user_function_ex (function_table=0x1,
object_pp=0x1, function_name=0x1, retval_ptr_ptr=0x1, param_count=1,
params=0x1, no_separation=1, symbol_table=0x1)
at /php-5.1.0RC1/Zend/zend_execute_API.c:571
#25 0x0823e998 in call_user_function (function_table=0xa0a2350,
object_pp=0x0, function_name=0xa43f80c, retval_ptr=0xbfe96ad0,
param_count=0, params=0xa448280)
at /php-5.1.0RC1/Zend/zend_execute_API.c:544
Provide short (and I mean SHORT) reproducing script before
you report any bugs about this.
--Jani
__destruct()'s are called before the user registered shutdown functions. This will not change so don't bother reporting a bug about this.
Eew. Is this a change in 5.0.5? Seemed not to be a problem in 5.0.4.
Not that it matters, as long as I know what to expect.
Is there a way to know the order of the objects destruction? It seems
logical that the least referenced objects would get destroyed first,
since they likely hold references to the higher refcounted objects. I
could use that to get the same effect though undeterministic.
Provide short (and I mean SHORT) reproducing script before you report any bugs about this.
Not worth it. It is something I can work around. I already have my
hands full coming up with short test cases for the bugs in Zend's
opcode cache for PHP 5.
Thank you for your comments! I got what I needed.
-steve