Bugs in 5.0.5 and 5.1 RCs

php.internals

steve roussey

21 years ago
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: 1) That the newly thrown exception blows up into a fatal error that doesn't list the file or line number. 2) 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--

Jani Taskinen

21 years ago
On Wed, 31 Aug 2005, steve wrote:
> At any rate, there are two problems: > 1) That the newly thrown exception blows up into a fatal error that > doesn't list the file or line number.
Example code?
> 2) 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

steve roussey

21 years ago
On 9/1/05, Jani Taskinen <sniper@iki.fi> wrote:
> __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--