Edit report at https://bugs.php.net/bug.php?id=64987&edit=1
ID: 64987
Comment by: ni...@php.net
Reported by: tyr...@php.net
Summary: unexpected result for call_user_func() in the
debug_backtrace()
Status: Assigned
Type: Bug
Package: Scripting Engine problem
Operating System: irrelevant
PHP Version: 5.3.26
Assigned To: laruence
Block user comment: N
Private report: N
New Comment:
> 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.
Misunderstanding ^^ I think having two entries is right (after all, both
functions *are* called, so they should both be in the trace). But I don't think
that the foo() call should copy the file&line info from the call_user_func()
call. It's a) redundant and b) inadequate, as the foo() call does *not* happen
in that line, but rather somewhere in the internals of call_user_func.
Now, for call_user_func in particular that distinction might be a bit fuzzy, as
call_user_func($foo) is roughly equivalent to $foo(), but what you say here
applies to all cases where a userland function is invoked from internal code.
If you just copied the file&line from the previous frame in those cases, then
they would point to some line that most likely does not even contain a
reference to the function (it just happens to be called from there, but can be
registered somewhere else).
Anyway, I don't really care much if it behaves one way or the other, but I do
think that the current behavior is the right one.
Previous Comments:
------------------------------------------------------------------------
[2013-06-07 11:25:56] tyr...@php.net
it seems that the xdebug debug backtrace works the same way as it was proposed
here:
Call Stack:
0.0016 639496 1. {main}() test.php:0
0.0026 639624 2. call_user_func() test.php:9
0.0026 639624 3. foo() test.php:9
0.0026 639624 4. bar() test.php:3
0.0026 639800 5. trigger_error() test.php:7
notice that it lists both the call_user_func() and the foo() call, both of the
pointing to the same file:line
------------------------------------------------------------------------
[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
