Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:106117
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>
In-Reply-To: <CAF+90c_MBgCRP67O=Y7BZynkbWofdqzoSuQDrNBE7ixmmHTYgw@mail.gmail.com>
Date: Sat, 29 Jun 2019 15:56:23 -0600
Message-ID: <CADVQu1SyBXCgtAaB4CPZiWYpMvbWS9+R3FQHKdX_cGE71jiZNQ@mail.gmail.com>
To: Nikita Popov <nikita.ppv@gmail.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="000000000000e9561f058c7d7731"
Subject: Re: [PHP-DEV] Memory leak in eval()'d code
From: dave@mudsite.com (David Walker)

--000000000000e9561f058c7d7731
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

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.com=
>
> 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 scaled =
case is
kind of =E2=80=9Cwrong=E2=80=9D in the sense that it=E2=80=99s exposing the=
 big in naming of the
anon class. Once the bug is resolved, the two behaviors shown should mimic
each other, wherein the memory footprint would grow as in the example
eval() case.

=E2=80=94
Dave

>
>

--000000000000e9561f058c7d7731--