Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:106118
MIME-Version: 1.0
References: <CAG9XoMQpojXq4fiLgqgi_9+ACTsrk3JLGGo4-0z5PiixtF33Ng@mail.gmail.com>
 <eb84978b97ef8e9481e8263f19e9456cf0f9ab24.camel@schlueters.de>
 <8f07c0dc-f9a5-8c76-1d48-0fac762bfc4f@gmail.com> <CAG9XoMSA5dZ+QYGiEC0+ObVnZqt44rojZo20y4nRSEg=zBFMtg@mail.gmail.com>
 <92dba455-17df-41dd-c523-bb0db3c12078@gmail.com> <003b01d52e49$4db89390$e929bab0$@jhdxr.com>
 <CAF+90c_8Yr7m+n1ys6g10EccSM31TT=XFtAm82bQai9XV9v8wA@mail.gmail.com>
 <000001d52e8f$a1f92b40$e5eb81c0$@jhdxr.com> <CAF+90c9gb3PHhAtzeHDou37aNtLeVeM4QpPzRxc9H0Km3442mw@mail.gmail.com>
 <CAG9XoMTPfw+hpVg-oVFAQghsFTOnWstJWYcf=Gc_sWydHN+5xA@mail.gmail.com>
 <CAF+90c_MBgCRP67O=Y7BZynkbWofdqzoSuQDrNBE7ixmmHTYgw@mail.gmail.com> <CADVQu1SyBXCgtAaB4CPZiWYpMvbWS9+R3FQHKdX_cGE71jiZNQ@mail.gmail.com>
In-Reply-To: <CADVQu1SyBXCgtAaB4CPZiWYpMvbWS9+R3FQHKdX_cGE71jiZNQ@mail.gmail.com>
Date: Sun, 30 Jun 2019 00:04:52 +0200
Message-ID: <CAF+90c9dCQJfDc9-zT9wSLx2iHOheUfpZ9PqpJK2JYppZ4kSPQ@mail.gmail.com>
To: David Walker <dave@mudsite.com>
Cc: Benjamin Morel <benjamin.morel@gmail.com>, CHU Zhaowei <me@jhdxr.com>, 
	PHP Internals <internals@lists.php.net>, Stanislav Malyshev <smalyshev@gmail.com>
Content-Type: multipart/alternative; boundary="000000000000945baa058c7d96e2"
Subject: Re: [PHP-DEV] Memory leak in eval()'d code
From: nikita.ppv@gmail.com (Nikita Popov)

--000000000000945baa058c7d96e2
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

On Sat, Jun 29, 2019 at 11:56 PM David Walker <dave@mudsite.com> wrote:

>
>
> On Sat, Jun 29, 2019 at 15:52 Nikita Popov <nikita.ppv@gmail.com> wrote:
>
>> On Sat, Jun 29, 2019 at 11:25 PM Benjamin Morel <benjamin.morel@gmail.co=
m
>> >
>> wrote:
>>
>>  The leaked memory is an allocated but unused class
>> entry. We could plug that particular leak -- but I should emphasize that
>> the current behavior is incorrect and once the key collision issue is
>> resolved this will create a new class for each eval.
>
>
> To clarify; you=E2=80=99re saying that the behavior seen in the non scale=
d case is
> kind of =E2=80=9Cwrong=E2=80=9D in the sense that it=E2=80=99s exposing t=
he big in naming of the
> anon class. Once the bug is resolved, the two behaviors shown should mimi=
c
> each other, wherein the memory footprint would grow as in the example
> eval() case.
>

What is the "non scaled case"? To repeat what I said earlier: Without eval
there is no and will not be a leak.

The bug is that eval() currently reuses an existing class instead of
creating a new one each time. Calling get_class(eval("return new class
{};")) should be returning a new string every time, while for OPs script it
currently does not.

tl;dr:

while (1) {
    get_class(new class {}); // should always return the same
    get_class(eval("return new class {};")); // should always return
different, currently may return same due to bug
}

Nikita

--000000000000945baa058c7d96e2--