Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:118778
MIME-Version: 1.0
References: <8392afe2-3f5b-5811-64fc-a38f40f9af7a@gmail.com>
In-Reply-To: <8392afe2-3f5b-5811-64fc-a38f40f9af7a@gmail.com>
Date: Fri, 7 Oct 2022 23:14:10 +0900
Message-ID: <CAGa2bXZPEbh352-zjntBrdAhwN3iazAFD9TGPLw=p2bZSOgo5Q@mail.gmail.com>
To: Arnaud Le Blanc <arnaud.lb@gmail.com>
Cc: PHP Internals List <internals@lists.php.net>
Content-Type: multipart/alternative; boundary="000000000000a0879e05ea726ebb"
Subject: Re: [PHP-DEV] Preventing stack overflows
From: yohgaki@ohgaki.net (Yasuo Ohgaki)

--000000000000a0879e05ea726ebb
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

2022=E5=B9=B410=E6=9C=887=E6=97=A5(=E9=87=91) 22:32 Arnaud Le Blanc <arnaud=
.lb@gmail.com>:

> Hi internals,
>
> I would like to propose a way to detect stack overflows before they
> happen, with the goal of improving debugability.
>
> Stack overflows are caused by excessive stack usage, typically due to
> deep recursions. Recursion in PHP doesn't use recursion internally, but
> some constructs still do, and it is not always possible to avoid without
> dramatically increasing complexity or degrading performances. Some
> examples of these constructs can be found at [1][2][3].
>
> Programs that overflow the stack are terminated with a SIGSEGV, and the
> user is left with no hint as to which code is causing the issue. This
> makes debugging difficult.
>
> Xdebug makes debugging easier by throwing an exception when the function
> call nesting level exceeds a certain limit [4], which is very useful.
> However, this can be overly limiting because this does not discriminate
> between the calls that actually use the stack and those that do not.
>
> Nikita proposed an other solution a while ago [5] that limits in terms
> of VM reentrances, so that only the constructs that actually cause
> internal recursion count towards the limit. One issue is that not all VM
> frames will consume the same amount of stack, and the maximum stack size
> depends on the system, so it's hard to determine a good default value
> for the limit that is not overly limiting.
>
> I would like to propose an alternative [6] that limits in terms of stack
> size. One issue is that it increases the internals complexity a bit, but
> this would make debugging easier without limiting recursion too much
> compared to what the system would allow.
>
> Any thoughts?
>
> [1] https://bugs.php.net/bug.php?id=3D64196
> [2] https://bugs.php.net/bug.php?id=3D75509
> [3] https://github.com/php/php-src/issues/8315
> [4] https://xdebug.org/docs/develop#max_nesting_level
> [5] https://externals.io/message/108348
> [6] https://github.com/php/php-src/pull/9104
>
>
The root cause that users cannot understand what happened is this:

$ php -n -r 'set_error_handler(function ($severity,$message, $filename,
$lineno) { throw new ErrorException($message, 0, $severity, $filename,
$lineno); });  function f() { f(); } f();'

Fatal error: Allowed memory size of 134217728 bytes exhausted (tried to
allocate 262144 bytes) in Command line code on line 1

When a fatal error happens, PHP does not allow  a stack dump.  Very old PHP
allowed users to catch E_ERROR by user error handler, but it is disabled to
prevent users from shooting their own foot.
I suppose allowing users to catch "only one" fatal error would solve many
issues as  well as infinite recursion.

Regards,

--
Yasuo Ohgaki
yohgaki@ohgaki.net

--000000000000a0879e05ea726ebb--