Edit report at https://bugs.php.net/bug.php?id=64987&edit=1
ID: 64987
Updated by: dmi...@php.net
Reported by: tyr...@php.net
Summary: unexpected result for call_user_func() in the
debug_backtrace()
-Status: Open
+Status: Assigned
Type: Bug
Package: Scripting Engine problem
Operating System: irrelevant
PHP Version: 5.3.26
-Assigned To:
+Assigned To: laruence
Block user comment: N
Private report: N
Previous Comments:
------------------------------------------------------------------------
[2013-06-07 10:52:28] tyr...@php.net
sorry, I've just realized that we had a bug report about this(#44428) closed by
Dmitry with not a bug.
I still think that it would worth a second look, we either say that this is an
internal call and then it shouldn't be in the debug_backtrace output or we say
that this is useful information to the userland and have it in the backtrace,
but
then we can't have the internal function excuse.
------------------------------------------------------------------------
[2013-06-07 10:48:14] tyr...@php.net
Description:
------------
call_user_func() generates two entry to the backtrace: one for the call of the
call_user_func with the callable arg and one for the call of the callable.
the problem is that the entry only has function and args entry, but no file or
line.
This happens because the execution reaches the break here:
http://lxr.php.net/xref/PHP_5_3/Zend/zend_builtin_functions.c#2161
Which based on the comment above is there to prevent touching the stack when we
are inside the error handler, which isn't the case here.
When discussing this with Nikita on irc he said that we shouldn't have two
entry
in the result in the first place for call_user_func, but I think that removing
one entry would have bigger impact on userland (there is a chance that some
people already remove the entry manually and this change would make it remove o
valid entry) compared to the change to fill out the information that was
ommited
before.
btw it seems that the suggested behavior was present between 5.0.0 and 5.0.5:
http://3v4l.org/jI9VI#v430
5.0.5 had two debug_backtrace related fix mentioned in the changelog(#30828 and
#28377) but from a quick glance on the description it seems to be irrelevant
from this behavior change.
In case if we decide to not change the current behavior, please turn this
report
into a documentation problem as it would be nice if the docs would reflect what
information will present (or missing) in which case.
Currently we only hint that the type and args can be missing in some case.
ps: the issue is still present in master and commenting out the if with that
break produces the expected result but ofc. that isn't the proper fix.
Test script:
---------------
<?php
function foo() {
var_dump(bar());
}
function bar() {
return debug_backtrace();
}
call_user_func("foo");
Expected result:
----------------
array(3) {
[0]=>
array(4) {
["file"]=>
string(9) "/in/jI9VI"
["line"]=>
int(3)
["function"]=>
string(3) "bar"
["args"]=>
array(0) {
}
}
[1]=>
array(4) {
["file"]=>
string(9) "/in/jI9VI"
["line"]=>
int(8)
["function"]=>
string(3) "foo"
["args"]=>
array(0) {
}
}
[2]=>
array(4) {
["file"]=>
string(9) "/in/jI9VI"
["line"]=>
int(8)
["function"]=>
string(14) "call_user_func"
["args"]=>
array(1) {
[0]=>
&string(3) "foo"
}
}
}
Actual result:
--------------
array(3) {
[0]=>
array(4) {
["file"]=>
string(9) "/in/jI9VI"
["line"]=>
int(3)
["function"]=>
string(3) "bar"
["args"]=>
array(0) {
}
}
[1]=>
array(2) {
["function"]=>
string(3) "foo"
["args"]=>
array(0) {
}
}
[2]=>
array(4) {
["file"]=>
string(9) "/in/jI9VI"
["line"]=>
int(8)
["function"]=>
string(14) "call_user_func"
["args"]=>
array(1) {
[0]=>
&string(3) "foo"
}
}
}
------------------------------------------------------------------------
--
Edit this bug report at https://bugs.php.net/bug.php?id=64987&edit=1
