Re: Memory leak in eval()'d code

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.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’re saying that the behavior seen in the non scaled case is > kind of “wrong” in the sense that it’s 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. > 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