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