Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:113821
MIME-Version: 1.0
References: <DM6PR07MB661815F45DBCBD0E2C1271D5F96E9@DM6PR07MB6618.namprd07.prod.outlook.com>
In-Reply-To: <DM6PR07MB661815F45DBCBD0E2C1271D5F96E9@DM6PR07MB6618.namprd07.prod.outlook.com>
Date: Sun, 28 Mar 2021 11:00:42 +0200
Message-ID: <CAF+90c_Us-h8jb5-KDSnykZ1omxHsbnv_ssp0Rnhjfw8Vt=fmw@mail.gmail.com>
To: tyson andre <tysonandre775@hotmail.com>
Cc: "internals@lists.php.net" <internals@lists.php.net>
Content-Type: multipart/alternative; boundary="000000000000e59aff05be950081"
Subject: Re: [PHP-DEV] [RFC] debug_backtrace_depth(int $limit=0): int
From: nikita.ppv@gmail.com (Nikita Popov)

--000000000000e59aff05be950081
Content-Type: text/plain; charset="UTF-8"

On Sat, Mar 13, 2021 at 6:30 PM tyson andre <tysonandre775@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

--000000000000e59aff05be950081--