On Sat, Mar 13, 2021 at 6:30 PM tyson andre <tysonandre...@hotmail.com> wrote:
> Hi internals, > > I've created a new RFC https://wiki.php.net/rfc/debug_backtrace_depth to > return the depth of the current stack trace. > > Inspecting the current stack trace depth is occasionally useful for > 1. Manually debugging with temporary debug statements > 2. Checking for potential infinite recursion or investigating reproducible > reports of infinite recursion > 3. Checking if code is likely to hit stack frame limits when run in > environments using extensions such as Xdebug > (https://xdebug.org/docs/all_settings#max_nesting_level , which also > checks for potential infinite recursion) > (note that Xdebug is a debugger - running php under xdebug is > significantly slower than without Xdebug) > > It is currently possible to compute the depth through > `count(debug_backtrace(DEBUG_BACKTRACE_IGNORE_ARGS, $limit=0))`, > but this is verbose, inefficient, and harder to read compared to returning > the depth directly. > > Thoughts? > > Thanks, > - Tyson There hasn't been much discussion on this one, probably because the functionality and use cases are so specific. I'm not really convinced by your examples. For the purpose of printing debug logs, using an engine-provided depth is non-ideal, because any intermediate helper functions will count towards the depth. Tracking your own depth will result in a more meaningful/predictable output. For tracking down infinite recursion, isn't this what the xdebug recursion limit is for? You'll directly get your recursive stack trace, which should make it obvious where the infinite recursion occurs. Using debug_backtrace_depth() for this purpose means that you actually already need to know where you are infinitely recursing in order to place the guard. If you want to find places where your code would hit the xdebug recursion limit, then why not run it under xdebug and find out, rather than trying to simulate the same behavior manually? That again requires that you actually place relevant guards in the first place, which makes this another chicken and egg problem. Regards, Nikita
