Bug #64987 [Asn]: unexpected result for call_user_func() in the debug_backtrace()

Edit report at https://bugs.php.net/bug.php?id=64987&edit=1 ID: 64987 Updated by: laruence@php.net Reported by: tyrael@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: A patch is added, introduced a new fn_flag ZEND_ACC_CALL_PROXY, applies to call_user_func, call_user_func_array, forward_static_call, reflectionMethod- >invoke etc and this only flag should only affects debug_backtrace handling ... thanks Previous Comments: ------------------------------------------------------------------------ [2013-06-09 09:00:08] laruence@php.net The following patch has been added/updated: Patch Name: add_call_proxy_flag.patch Revision: 1370768408 URL: https://bugs.php.net/patch-display.php?bug=64987&patch=add_call_proxy_flag.patch&revision=1370768408 ------------------------------------------------------------------------ [2013-06-07 17:15:45] laruence@php.net 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) ------------------------------------------------------------------------ [2013-06-07 17:08:16] laruence@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] tyrael@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] nikic@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. ------------------------------------------------------------------------ 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