Edit report at https://bugs.php.net/bug.php?id=64987&edit=1
ID: 64987
Updated by: larue...@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:
hmm, I may find a solution, use tricky ZEND_CALL_VIA_HANDLER fn_flags, for
call_user_func, may like:
$ git diff
diff --git a/ext/standard/basic_functions.c b/ext/standard/basic_functions.c
index 9c91404..03f836e 100644
--- a/ext/standard/basic_functions.c
+++ b/ext/standard/basic_functions.c
@@ -2983,7 +2983,7 @@ const zend_function_entry basic_functions[] = { /* {{{ */
PHP_FE(error_log,
arginfo_error_log)
PHP_FE(error_get_last,
arginfo_error_get_last)
- PHP_FE(call_user_func,
arginfo_call_user_func)
+ ZEND_FENTRY(call_user_func, ZEND_FN(call_user_func),
arginfo_call_user_func, ZEND_ACC_CALL_VIA_HANDLER|ZEND_ACC_
PUBLIC)
PHP_FE(call_user_func_array,
arginfo_call_user_func_array)
PHP_DEP_FE(call_user_method,
arginfo_call_user_method)
PHP_DEP_FE(call_user_method_array,
arginfo_call_user_method_array)
Previous Comments:
------------------------------------------------------------------------
[2013-06-07 17:08:16] larue...@php.net
I understood your point, I just don't know how to fix other related functions
once.
call_user_func, call_method, reflectionmethod->invoke,
reflectionFunction->invoke
etc.
------------------------------------------------------------------------
[2013-06-07 14:05:34] tyr...@php.net
from the userland developer POV (=debug_backtrace() target audience) the foo
call
happens in the call_user_func line.
generating bogus entry because we unintentionally leak implementation details
to
the userland is a bad thing imo.
I agree that the fixing this via allowing all zend functions to fetch the info
from the previous frame would be a bad thing, but it wasn't my intention to
suggest that.
------------------------------------------------------------------------
[2013-06-07 12:43:36] ni...@php.net
> 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.
------------------------------------------------------------------------
[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.
------------------------------------------------------------------------
The remainder of the comments for this report are too long. To view
the rest of the comments, please view the bug report online at
https://bugs.php.net/bug.php?id=64987
--
Edit this bug report at https://bugs.php.net/bug.php?id=64987&edit=1
