Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:124340
Precedence: bulk
MIME-Version: 1.0
References: <fbf45a9a-0385-4c42-a6a0-4f3ee1c8728d@app.fastmail.com> <520ee513-d6fe-a658-5845-00296a9e08a2@php.net>
In-Reply-To: <520ee513-d6fe-a658-5845-00296a9e08a2@php.net>
Date: Wed, 10 Jul 2024 12:47:18 +0200
Message-ID: <CAPyj-LA8WhEKGmvSuDVS3=X3L8XTtdSNsquWT0uZ5qgSUQEyGA@mail.gmail.com>
Subject: Re: [PHP-DEV] [RFC] Property Hook improvements
To: php internals <internals@lists.php.net>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
From: tovilo.ilija@gmail.com (Ilija Tovilo)

Hi Derick

On Wed, Jul 10, 2024 at 11:32=E2=80=AFAM Derick Rethans <derick@php.net> wr=
ote:
>
> On Mon, 1 Jul 2024, Larry Garfield wrote:
>
> >
> > https://wiki.php.net/rfc/hook_improvements
>
> 1. Remove the proactive guard against recursive backing value access
>
>         "which would eventually trigger a stack overflow"
>
> Would it though? PHP 8.4 has an actual protection against this now,
> instead of getting the white-screen-of-death.
>
> Not that it matters much, but it's probably good to be precise in the
> language.

Yes, this excerpt is referring to the PHP stack overflow detection,
which will throw an exception rather than segfault. That is, on all
the architectures that already support stack overflow detection. We're
just reusing the same mechanism already used for normal function
calls.

---

Hi Claude

> 1. Removing the guard against recursion is sensible to me, as the sort of=
 bug it is supposed to prevent is not specific to property accessors. IMO, =
a better solution to the issue is to implement a global upper limit on the =
call stack size. Currently, I am able to generate a call stack of more than=
 10 millions items before an OOM error occurs; PHP should have thrown a sta=
ck overflow error long before that. But this is entirely orthogonal to prop=
erty hooks.

PHP allows using recursion for algorithms on arbitrarily large data
because function calls do not cause the C stack to grow. Limiting the
PHP stack size would thus require these algorithms to be rewritten to
iterative ones, which can make them more complicated. What we could do
is check for stack size on OOM and indicate that the OOM was most
likely caused by infinite recursion.

Anyway, This does not really apply to hooks, because it will (usually)
cause VM reentry for recursion, growing the stack size and thus
triggering the "fast" stack overflow detection error.

Ilija