RE: [PHP-DEV] Memory leak in eval()'d code

[CHU Zhaowei]

Eval is not the only case that will cause memory usage growing actually. 
https://3v4l.org/fPhlU is an example using include inside a loop, which is used 
to simulate including same file several times. I agree it might be trivial to 
improve for eval since it's not recommended to use due to security concern 
nowadays. But I think we should pay attention to this issue since 
include/require behave the same.

In theory, I understand how it happens. You won't be surprised if you copy the 
code and paste it several times and more memory is used. It's reasonable that 
more memory is needed to compile longer codes. Include several times just work 
like copy&paste several times. But since we are including the same file, is it 
possible to detect and reuse the space?

Regards,
CHU Zhaowei

> -Original Message-
> From: Stanislav Malyshev 
> Sent: Sunday, June 30, 2019 10:43 AM
> To: Benjamin Morel ; Nikita Popov
> 
> Cc: CHU Zhaowei ; PHP Internals 
> Subject: Re: [PHP-DEV] Memory leak in eval()'d code
> 
> Hi!
> 
> > I still don't understand *why*, then, the memory stays flat when the
> > new class does not happen in eval():
> 
> Because that code creates only one class.
> 
> > I checked get_class() for all instances returned, **it's always the
> > same class name whether it's called from eval() or not**, so this code
> > should only ever create a single class in memory, right? Why the leak with
> eval()?
> 
> There's no leak, eval() just creates new class each time.
> --
> Stas Malyshev
> smalys...@gmail.com
> 
> --
> PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit:
> http://www.php.net/unsub.php
> 




--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] Memory leak in eval()'d code

[Stanislav Malyshev]

Hi!

> I still don't understand *why*, then, the memory stays flat when the new
> class does not happen in eval():

Because that code creates only one class.

> I checked get_class() for all instances returned, **it's always the same
> class name whether it's called from eval() or not**, so this code should
> only ever create a single class in memory, right? Why the leak with eval()?

There's no leak, eval() just creates new class each time.
-- 
Stas Malyshev
smalys...@gmail.com

-- 
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] Memory leak in eval()'d code

[Benjamin Morel]

>
> 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
> }

Ok thank you, anyway the good news is that I found a workaround for now
(creating classes of a given type once then cloning). And if I understand
correctly, once the issue you mention is resolved (and get_class() returns
a distinct class every time), I should have another alternative:

```
$object = eval('return new class (...) {};');
$class = get_class($object);
$anotherObjectOfSameClass = new $class();
```

And I do understand that my use case is border line, and does not deserve
too much attention.
It's very useful to be able to perform instanceof on objects that
dynamically implement an arbritary set of interfaces, though.

Ben

Re: [PHP-DEV] Memory leak in eval()'d code

[Nikita Popov]

On Sat, Jun 29, 2019 at 11:56 PM David Walker  wrote:

>
>
> On Sat, Jun 29, 2019 at 15:52 Nikita Popov  wrote:
>
>> On Sat, Jun 29, 2019 at 11:25 PM Benjamin Morel > >
>> 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

Re: [PHP-DEV] Memory leak in eval()'d code

[David Walker]

On Sat, Jun 29, 2019 at 15:52 Nikita Popov  wrote:

> On Sat, Jun 29, 2019 at 11:25 PM Benjamin Morel 
> 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.

—
Dave

>
>

Re: [PHP-DEV] Memory leak in eval()'d code

[Nikita Popov]

On Sat, Jun 29, 2019 at 11:25 PM Benjamin Morel 
wrote:

> > The problem here is that OP is *creating* many classes (the fact that
> they are anonymous ultimately doesn't matter) by eval'ing code. That is
> what causes the leak.
>
> I still don't understand why there is no leak when *not* using eval(),
> though.
>
> Ben
>

Without eval you are creating many objects of the same anonymous class.
With eval you are creating a single object each for many anonymous classes.
In the first case there is only a single class, in the second there are as
many classes as there are eval()s.

That's the theory. In practice we have a long-standing bug with RTD key
collisions -- this means that the names generated for anonymous classes
(and closures for that matter) are not actually unique. For anonymous
classes the current workaround is to reuse the existing class definition if
an RTD key collision occurs. For your original code (and I should say that
this is very specific to the code because it is susceptible to memory
layout details) it happens that the RTD key for all those anonymous classes
is the same, so in the end you end up with just one class definition also
in the eval() case. 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.

Nikita

Re: [PHP-DEV] Memory leak in eval()'d code

[Benjamin Morel]

> The problem here is that OP is *creating* many classes (the fact that
they are anonymous ultimately doesn't matter) by eval'ing code. That is
what causes the leak.

I still don't understand why there is no leak when *not* using eval(),
though.

Ben

Re: [PHP-DEV] Memory leak in eval()'d code

[Nikita Popov]

On Sat, Jun 29, 2019 at 5:31 PM CHU Zhaowei  wrote:

> Thanks for the example. Now I understand the root cause. There is a
> similar bug report(https://bugs.php.net/bug.php?id=74938) for anonymous
> function. I thought it leaked for the same reason, but now I think I’m
> wrong. We don’t have to create new classes for them since they are all
> instances of Closure class, and it’s not possible to create opaque
> reference for functions.  __FUNCTION__ returns “{closure}”. Could you take
> a look?
>

This leaks for the same reason (function definition is not garbage
collected), but in this case we could indeed implement the garbage
collection without any observable changes to semantics. I don't think it
will be simple to do this though.

 Back to the anonymous class, I’m thinking if we can have any workaround
> for this issue, otherwise it will be a huge problem if someone wants to
> write applications running for a long time. It will be a memory leak that
> cannot be fixed in userland code unless he decides to drop anonymous class
> at all.
>

I think you got caught up in a wrong premise here: Just using anonymous
classes does not cause leaks. The problem here is that OP is *creating*
many classes (the fact that they are anonymous ultimately doesn't matter)
by eval'ing code. That is what causes the leak. Unless you are doing
something like this (which you obviously shouldn't, for more reasons than
this), there is nothing to worry about. As such, I don't really think there
is a problem worth solving here.

Nikita

Since most of the use cases should not have opaque references, can we add a
> flag in zval to indicate if an object has this kind of reference? The
> number of methods to create such opaque references should be limited.
> __CLASS__, get_class(), reflections, clone. Did I miss any other way? With
> the help of this flag, we are able to know if it’s safe to remove the class
> definition during destruction.
>


Regards,
>
> CHU Zhaowei
>
>
>
> *From:* Nikita Popov 
> *Sent:* Saturday, June 29, 2019 3:58 PM
> *To:* CHU Zhaowei 
> *Cc:* Stanislav Malyshev ; Benjamin Morel <
> benjamin.mo...@gmail.com>; PHP Internals 
> *Subject:* Re: [PHP-DEV] Memory leak in eval()'d code
>
>
>
> On Sat, Jun 29, 2019 at 9:07 AM CHU Zhaowei  wrote:
>
> I think we missed the point here. Clousre, or anonymous class, should not
> be considered as normal class. We expect normal class existing once we
> declare it till end of script. However, for anonymous class, it's usually
> used within certain scope, so not only the instances, the class itself
> should be included in the GC as well.
> I guess the problem here is we didn't GC the space for definition of
> anonymous classes.
>
> Regards,
> CHU Zhaowei
>
>
>
> As Johannes already pointed out, we cannot garbage collect anonymous class
> definitions due to the existence of opaque references. A simple example of
> code that currently works:
>
>
>
> $obj = eval('return new class {}');
>
> $class = get_class($obj); // create opaque reference
>
> unset($obj); // drop last direct reference
>
> $obj = new $class;
>
>
>
> In the end, an anonymous class is essentially a class with a random name
> and some inline construction sugar, but apart from that does not differ
> from ordinary classes. (I've also seen some calls to allow syntax like
> $class = class {}; that would make that even more obvious.)
>
>
>
> The situation here would be different if we had first-class classes and
> did not refer to classes by name. But as-is, I don't think garbage
> collecting anonymous classes is a possibility.
>
>
>
> Nikita
>
>
>
> > -Original Message-
> > From: Stanislav Malyshev 
> > Sent: Saturday, June 29, 2019 6:52 AM
> > To: Benjamin Morel 
> > Cc: PHP Internals 
> > Subject: Re: [PHP-DEV] Memory leak in eval()'d code
> >
> >
> >
> > On 6/28/19 3:37 PM, Benjamin Morel wrote:
> > > That's not a "leak". You create new objects (in this case,
> classes),
> > > they take memory.
> > >
> > >
> > > Why do they not "leak" memory without eval() then? Replace with
> > > `$object = new class {};` and memory usage stays flat.
> > > There has do be some kind of garbage collection for these anonymous
> classes.
> >
> > AFAIR this does not create new classes, since it's the same code, and
> same code
> > means same class. But eval() has new code every time, thus new class.
> Generally
> > I don't think PHP has any operation that can destroy an existing class.
> It won't be
> > easy too since you don't know whether there are any objects of this class
> > around (unless you're in shutdown).
> >
> > --
> > Stas Malyshev
> > smalys...@gmail.com
> >
> > --
> > PHP Internals - PHP Runtime Development Mailing List To unsubscribe,
> visit:
> > http://www.php.net/unsub.php
> >
>
>
>
>
> --
> PHP Internals - PHP Runtime Development Mailing List
> To unsubscribe, visit: http://www.php.net/unsub.php
>
>

RE: [PHP-DEV] Memory leak in eval()'d code

[CHU Zhaowei]

Thanks for the example. Now I understand the root cause. There is a similar bug 
report(https://bugs.php.net/bug.php?id=74938) for anonymous function. I thought 
it leaked for the same reason, but now I think I’m wrong. We don’t have to 
create new classes for them since they are all instances of Closure class, and 
it’s not possible to create opaque reference for functions.  __FUNCTION__ 
returns “{closure}”. Could you take a look?

 

Back to the anonymous class, I’m thinking if we can have any workaround for 
this issue, otherwise it will be a huge problem if someone wants to write 
applications running for a long time. It will be a memory leak that cannot be 
fixed in userland code unless he decides to drop anonymous class at all. Since 
most of the use cases should not have opaque references, can we add a flag in 
zval to indicate if an object has this kind of reference? The number of methods 
to create such opaque references should be limited. __CLASS__, get_class(), 
reflections, clone. Did I miss any other way? With the help of this flag, we 
are able to know if it’s safe to remove the class definition during destruction.

 

Regards,

CHU Zhaowei

 

From: Nikita Popov  
Sent: Saturday, June 29, 2019 3:58 PM
To: CHU Zhaowei 
Cc: Stanislav Malyshev ; Benjamin Morel 
; PHP Internals 
Subject: Re: [PHP-DEV] Memory leak in eval()'d code

 

On Sat, Jun 29, 2019 at 9:07 AM CHU Zhaowei mailto:m...@jhdxr.com> > wrote:

I think we missed the point here. Clousre, or anonymous class, should not be 
considered as normal class. We expect normal class existing once we declare it 
till end of script. However, for anonymous class, it's usually used within 
certain scope, so not only the instances, the class itself should be included 
in the GC as well. 
I guess the problem here is we didn't GC the space for definition of anonymous 
classes.

Regards,
CHU Zhaowei

 

As Johannes already pointed out, we cannot garbage collect anonymous class 
definitions due to the existence of opaque references. A simple example of code 
that currently works:

 

$obj = eval('return new class {}');

$class = get_class($obj); // create opaque reference

unset($obj); // drop last direct reference

$obj = new $class;

 

In the end, an anonymous class is essentially a class with a random name and 
some inline construction sugar, but apart from that does not differ from 
ordinary classes. (I've also seen some calls to allow syntax like $class = 
class {}; that would make that even more obvious.)

 

The situation here would be different if we had first-class classes and did not 
refer to classes by name. But as-is, I don't think garbage collecting anonymous 
classes is a possibility.

 

Nikita

 

> -Original Message-
> From: Stanislav Malyshev mailto:smalys...@gmail.com> >
> Sent: Saturday, June 29, 2019 6:52 AM
> To: Benjamin Morel  <mailto:benjamin.mo...@gmail.com> >
> Cc: PHP Internals mailto:internals@lists.php.net> >
> Subject: Re: [PHP-DEV] Memory leak in eval()'d code
> 
> 
> 
> On 6/28/19 3:37 PM, Benjamin Morel wrote:
> > That's not a "leak". You create new objects (in this case, classes),
> > they take memory.
> >
> >
> > Why do they not "leak" memory without eval() then? Replace with
> > `$object = new class {};` and memory usage stays flat.
> > There has do be some kind of garbage collection for these anonymous classes.
> 
> AFAIR this does not create new classes, since it's the same code, and same 
> code
> means same class. But eval() has new code every time, thus new class. 
> Generally
> I don't think PHP has any operation that can destroy an existing class. It 
> won't be
> easy too since you don't know whether there are any objects of this class
> around (unless you're in shutdown).
> 
> --
> Stas Malyshev
> smalys...@gmail.com <mailto:smalys...@gmail.com> 
> 
> --
> PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit:
> http://www.php.net/unsub.php
> 




-- 
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] Memory leak in eval()'d code

[Benjamin Morel]

> As Johannes already pointed out, we cannot garbage collect anonymous
class definitions due to the existence of opaque references.

I still don't understand *why*, then, the memory stays flat when the new
class does not happen in eval():

```
for ($i = 0; $i < 100; $i++) {
$object = new class {};

if ($i % 1000 == 0) {
echo memory_get_usage() . "\n";
}
}
```

I checked get_class() for all instances returned, **it's always the same
class name whether it's called from eval() or not**, so this code should
only ever create a single class in memory, right? Why the leak with eval()?

> $class = get_class($obj);
> $obj = new $class;

Interesting. Can this behaviour be relied upon (is it documented?), or is
this an implementation detail that may change at any time?

Thank you,
Ben

Re: [PHP-DEV] Memory leak in eval()'d code

[Nikita Popov]

On Sat, Jun 29, 2019 at 9:07 AM CHU Zhaowei  wrote:

> I think we missed the point here. Clousre, or anonymous class, should not
> be considered as normal class. We expect normal class existing once we
> declare it till end of script. However, for anonymous class, it's usually
> used within certain scope, so not only the instances, the class itself
> should be included in the GC as well.
> I guess the problem here is we didn't GC the space for definition of
> anonymous classes.
>
> Regards,
> CHU Zhaowei
>

As Johannes already pointed out, we cannot garbage collect anonymous class
definitions due to the existence of opaque references. A simple example of
code that currently works:

$obj = eval('return new class {}');
$class = get_class($obj); // create opaque reference
unset($obj); // drop last direct reference
$obj = new $class;

In the end, an anonymous class is essentially a class with a random name
and some inline construction sugar, but apart from that does not differ
from ordinary classes. (I've also seen some calls to allow syntax like
$class = class {}; that would make that even more obvious.)

The situation here would be different if we had first-class classes and did
not refer to classes by name. But as-is, I don't think garbage collecting
anonymous classes is a possibility.

Nikita

> -Original Message-
> > From: Stanislav Malyshev 
> > Sent: Saturday, June 29, 2019 6:52 AM
> > To: Benjamin Morel 
> > Cc: PHP Internals 
> > Subject: Re: [PHP-DEV] Memory leak in eval()'d code
> >
> >
> >
> > On 6/28/19 3:37 PM, Benjamin Morel wrote:
> > > That's not a "leak". You create new objects (in this case,
> classes),
> > > they take memory.
> > >
> > >
> > > Why do they not "leak" memory without eval() then? Replace with
> > > `$object = new class {};` and memory usage stays flat.
> > > There has do be some kind of garbage collection for these anonymous
> classes.
> >
> > AFAIR this does not create new classes, since it's the same code, and
> same code
> > means same class. But eval() has new code every time, thus new class.
> Generally
> > I don't think PHP has any operation that can destroy an existing class.
> It won't be
> > easy too since you don't know whether there are any objects of this class
> > around (unless you're in shutdown).
> >
> > --
> > Stas Malyshev
> > smalys...@gmail.com
> >
> > --
> > PHP Internals - PHP Runtime Development Mailing List To unsubscribe,
> visit:
> > http://www.php.net/unsub.php
> >
>
>
>
>
> --
> PHP Internals - PHP Runtime Development Mailing List
> To unsubscribe, visit: http://www.php.net/unsub.php
>
>

RE: [PHP-DEV] Memory leak in eval()'d code

[CHU Zhaowei]

I think we missed the point here. Clousre, or anonymous class, should not be 
considered as normal class. We expect normal class existing once we declare it 
till end of script. However, for anonymous class, it's usually used within 
certain scope, so not only the instances, the class itself should be included 
in the GC as well. 
I guess the problem here is we didn't GC the space for definition of anonymous 
classes.

Regards,
CHU Zhaowei

> -Original Message-
> From: Stanislav Malyshev 
> Sent: Saturday, June 29, 2019 6:52 AM
> To: Benjamin Morel 
> Cc: PHP Internals 
> Subject: Re: [PHP-DEV] Memory leak in eval()'d code
> 
> 
> 
> On 6/28/19 3:37 PM, Benjamin Morel wrote:
> > That's not a "leak". You create new objects (in this case, classes),
> > they take memory.
> >
> >
> > Why do they not "leak" memory without eval() then? Replace with
> > `$object = new class {};` and memory usage stays flat.
> > There has do be some kind of garbage collection for these anonymous classes.
> 
> AFAIR this does not create new classes, since it's the same code, and same 
> code
> means same class. But eval() has new code every time, thus new class. 
> Generally
> I don't think PHP has any operation that can destroy an existing class. It 
> won't be
> easy too since you don't know whether there are any objects of this class
> around (unless you're in shutdown).
> 
> --
> Stas Malyshev
> smalys...@gmail.com
> 
> --
> PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit:
> http://www.php.net/unsub.php
> 




--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] Memory leak in eval()'d code

[Stanislav Malyshev]

On 6/28/19 3:37 PM, Benjamin Morel wrote:
> That's not a "leak". You create new objects (in this case, classes),
> they take memory.
> 
> 
> Why do they not "leak" memory without eval() then? Replace with `$object
> = new class {};` and memory usage stays flat.
> There has do be some kind of garbage collection for these anonymous classes.

AFAIR this does not create new classes, since it's the same code, and
same code means same class. But eval() has new code every time, thus new
class. Generally I don't think PHP has any operation that can destroy an
existing class. It won't be easy too since you don't know whether there
are any objects of this class around (unless you're in shutdown).

-- 
Stas Malyshev
smalys...@gmail.com

-- 
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] Memory leak in eval()'d code

[Benjamin Morel]

>
> That's not a "leak". You create new objects (in this case, classes),
> they take memory.


Why do they not "leak" memory without eval() then? Replace with `$object =
new class {};` and memory usage stays flat.
There has do be some kind of garbage collection for these anonymous classes.

Ben

Re: [PHP-DEV] Memory leak in eval()'d code

[Stanislav Malyshev]

Hi!

> I case this is non-trivial to fix. Each invocation recompile a new
> piece of code, which creates a new class.

That's not a "leak". You create new objects (in this case, classes),
they take memory.

-- 
Stas Malyshev
smalys...@gmail.com

-- 
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] Memory leak in eval()'d code

[Johannes Schlüter]

On June 28, 2019 6:49:49 PM GMT+02:00, Benjamin Morel 
 wrote:
>
>> or unload the class once
>> it's not needed anymore (which is hard to detect with reflection and
>> other mechanisms which aren't bound to an instance's zval and also
>not
>> cheap)
>
>AFAIK, unloading a class is not possible from userland, I guess you're
>talking about detecting this in PHP itself?

Correct.

>Anyway, that's an edge case, I found a workaround which is to keep a
>cache
>of freshly created objects, indexed by interface name(s).
>Anytime I request a combination of types that's already been handled in
>the
>past, I return a clone of the cached object.
>
>Even though the possible combinations of types are huge and impossible
>to
>predict in advance, there are never more than a handful of such
>combinations used in a single document, and I'd be surprised if there
>are
>actually that many combinations actually used in the wild. So this
>should
>hardly be a problem.

This is going to be off-topic for his list: you could rethink your approach. 
Maybe you can generate the classes only on demand (if you can derive the 
information from a class name an evil way is `function __autoload($classname) { 
/* figure out what is needed */ eval("class $classname { ...}")}` ... 
absolutely evil, but hides the machinery) or you could rethink whether you 
really need distinct classes or whether a single type with accessor routines 
(either some custom or __call/__set/__get) isn't sufficient. Or something else 
...

johannes

--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] Memory leak in eval()'d code

[Benjamin Morel]

> Theoretical it is thinkable we could either detect equal classes (but
> unlikely to happen ... if it's the same why do it in eval, zthus cost
> likely is higher than benefit in most cases?)

Thanks for your reply. I do it in eval() because schema.org has many types
(more than 600 at the moment), and each object ("Thing") can be an instance
of one or more of these types.
This creates an unmanageable number of possible combinations that I cannot
pre-compute, so I need to dynamically create a definition for an object
that implements an arbitrary number of interfaces.

> or unload the class once
> it's not needed anymore (which is hard to detect with reflection and
> other mechanisms which aren't bound to an instance's zval and also not
> cheap)

AFAIK, unloading a class is not possible from userland, I guess you're
talking about detecting this in PHP itself?

Anyway, that's an edge case, I found a workaround which is to keep a cache
of freshly created objects, indexed by interface name(s).
Anytime I request a combination of types that's already been handled in the
past, I return a clone of the cached object.

Even though the possible combinations of types are huge and impossible to
predict in advance, there are never more than a handful of such
combinations used in a single document, and I'd be surprised if there are
actually that many combinations actually used in the wild. So this should
hardly be a problem.

Thank you,
Ben


On Fri, 28 Jun 2019 at 17:59, Johannes Schlüter 
wrote:

> On Fri, 2019-06-28 at 02:41 +0200, Benjamin Morel wrote:
> > Hi internals,
> >
> > I've tracked down a memory leak to an anonymous class created within
> > eval():
> >
> > ```
> > for ($i = 0; $i < 100; $i++) {
> > $object = eval('return new class {};');
> >
> > if ($i % 1000 == 0) {
> > echo memory_get_usage() . "\n";
> > }
> > }
> >
> > ```
> >
> > The memory usage quickly ramps up and memory_limit is reached in
> > seconds.
> > Without eval(), the memory usage stays flat. I'm on 7.3.6.
> >
> > *Is this a bug?* Or is this some inherent limitation of eval() that
> > cannot
> > be fixed?
>
> I case this is non-trivial to fix. Each invocation recompile a new
> piece of code, which creates a new class.
>
> Similar to
>
> for ($i = 0; $i < 100; $i++) {
>   eval("function f$i(){}");
> }
> f1();
> f2();
>...
>
> or
>
>   for ($i = 0; $i < 100; $i++) {
> file_put_contents("c$i.php", 'return new class {};');
> $object = include "c$i.php";
>}
>
> Theoretical it is thinkable we could either detect equal classes (but
> unlikely to happen ... if it's the same why do it in eval, zthus cost
> likely is higher than benefit in most cases?) or unload the class once
> it's not needed anymore (which is hard to detect with reflection and
> other mechanisms which aren't bound to an instance's zval and also not
> cheap)
>
> johannes
>
>

Re: [PHP-DEV] Memory leak in eval()'d code

[Johannes Schlüter]

On Fri, 2019-06-28 at 02:41 +0200, Benjamin Morel wrote:
> Hi internals,
> 
> I've tracked down a memory leak to an anonymous class created within
> eval():
> 
> ```
> for ($i = 0; $i < 100; $i++) {
> $object = eval('return new class {};');
> 
> if ($i % 1000 == 0) {
> echo memory_get_usage() . "\n";
> }
> }
> 
> ```
> 
> The memory usage quickly ramps up and memory_limit is reached in
> seconds.
> Without eval(), the memory usage stays flat. I'm on 7.3.6.
> 
> *Is this a bug?* Or is this some inherent limitation of eval() that
> cannot
> be fixed?

I case this is non-trivial to fix. Each invocation recompile a new
piece of code, which creates a new class.

Similar to

for ($i = 0; $i < 100; $i++) {
  eval("function f$i(){}");
}
f1();
f2();
   ...

or

  for ($i = 0; $i < 100; $i++) {
file_put_contents("c$i.php", 'return new class {};');
$object = include "c$i.php";  
   }

Theoretical it is thinkable we could either detect equal classes (but
unlikely to happen ... if it's the same why do it in eval, zthus cost
likely is higher than benefit in most cases?) or unload the class once
it's not needed anymore (which is hard to detect with reflection and
other mechanisms which aren't bound to an instance's zval and also not
cheap)

johannes


-- 
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

[PHP-DEV] Memory leak in eval()'d code

[Benjamin Morel]

Hi internals,

I've tracked down a memory leak to an anonymous class created within eval():

```
for ($i = 0; $i < 100; $i++) {
$object = eval('return new class {};');

if ($i % 1000 == 0) {
echo memory_get_usage() . "\n";
}
}

```

The memory usage quickly ramps up and memory_limit is reached in seconds.
Without eval(), the memory usage stays flat. I'm on 7.3.6.

*Is this a bug?* Or is this some inherent limitation of eval() that cannot
be fixed?

Thanks for any insight.
Ben

*In case you're wondering (I'm sure you are!), I need this to dynamically
create an object that implements an arbitrary number of interfaces
, for a
schema.org  structured data reader library.*

Re: [PHP-DEV] Memory leak in include()/require() ?

[Peter Wang]

More information about this bug:

To stably re-produce the bug, we need create 2 files.
// file1.php, can be empty

// leak.php
 wrote:

> Hi,
>
> I found that the memory leak is actually related to APC,
> even with the latest version of PHP (5.3.25) and latest version of APC
> (3.1.13),
> the memory leak is still there, to re-produce the bug,
> just run this script and watch the memory usage of the php process
> (please run with: php -d apc.enable_cli=1 )
>
> 
> touch('file1.php');
> while (true) {
> $file = 'file1.php';
> require($file);
> }
>
> if run with  -dapc.enable_cli=0, it does not leak memory.
>
> thanks.
>
>
> On Thu, May 16, 2013 at 11:40 AM, Stas Malyshev wrote:
>
>> Hi!
>>
>> > hi, did anyone come across the memory leak of require()/include(),
>> > I just saw this bug report: https://bugs.php.net/bug.php?id=47038,
>> > but it was closed with nothing explained.
>>
>> This bug report was closed because the bug it describes was fixed. It is
>> explained so right on the bug page.
>>
>> > the php version I used:
>> >
>> > php --version
>> > PHP 5.3.6-13ubuntu3.9 with Suhosin-Patch (cli) (built: Sep 12 2012
>> 19:00:27)
>> > Copyright (c) 1997-2011 The PHP Group
>> > Zend Engine v2.3.0, Copyright (c) 1998-2011 Zend Technologies
>>
>> If you see the memory leak with current version (5.4.15/5.3.25) please
>> submit a bug report containing the reproduction script and what happens
>> when you run it. See the guidelines here:
>> https://bugs.php.net/how-to-report.php
>>
>>
>> --
>> Stanislav Malyshev, Software Architect
>> SugarCRM: http://www.sugarcrm.com/
>> (408)454-6900 ext. 227
>>
>
>

Re: [PHP-DEV] Memory leak in include()/require() ?

[Peter Wang]

Hi,

Thanks for your information.
I also tested the latest stable version of APC
(3.1.9),
which has the same problem.




On Fri, May 17, 2013 at 9:42 AM, Leigh  wrote:

> > > > I found that the memory leak is actually related to APC,
> > > > even with the latest version of PHP (5.3.25) and latest version of
> APC
> > > > (3.1.13),
>
> Just to make sure it's extra clear, APC 3.1.13 is a beta release. 3.1.14
> was released and un-released because of memory leak issues.
>
> If you're still using PHP 5.3 you might want to see if the issue is still
> there in the latest *stable* APC
>

Re: [PHP-DEV] Memory leak in include()/require() ?

[Leigh]

> > > I found that the memory leak is actually related to APC,
> > > even with the latest version of PHP (5.3.25) and latest version of APC
> > > (3.1.13),

Just to make sure it's extra clear, APC 3.1.13 is a beta release. 3.1.14
was released and un-released because of memory leak issues.

If you're still using PHP 5.3 you might want to see if the issue is still
there in the latest *stable* APC

Re: [PHP-DEV] Memory leak in include()/require() ?

[Peter Wang]

Hi,
the bug report is here:  https://bugs.php.net/bug.php?id=64859

thanks.


On Thu, May 16, 2013 at 8:57 PM, Stas Malyshev wrote:

> Hi!
>
> > I found that the memory leak is actually related to APC,
> > even with the latest version of PHP (5.3.25) and latest version of APC
> > (3.1.13),
>
> Please submit the bug on bugs.php.net with package "apc" - putting there
> reproducing script and describing exactly what you see when it is running.
>
> Thanks,
> --
> Stanislav Malyshev, Software Architect
> SugarCRM: http://www.sugarcrm.com/
> (408)454-6900 ext. 227
>

Re: [PHP-DEV] Memory leak in include()/require() ?

[Stas Malyshev]

Hi!

> I found that the memory leak is actually related to APC,
> even with the latest version of PHP (5.3.25) and latest version of APC
> (3.1.13),

Please submit the bug on bugs.php.net with package "apc" - putting there
reproducing script and describing exactly what you see when it is running.

Thanks,
-- 
Stanislav Malyshev, Software Architect
SugarCRM: http://www.sugarcrm.com/
(408)454-6900 ext. 227

-- 
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] Memory leak in include()/require() ?

[Peter Wang]

Hi,

I found that the memory leak is actually related to APC,
even with the latest version of PHP (5.3.25) and latest version of APC
(3.1.13),
the memory leak is still there, to re-produce the bug,
just run this script and watch the memory usage of the php process
(please run with: php -d apc.enable_cli=1 )

wrote:

> Hi!
>
> > hi, did anyone come across the memory leak of require()/include(),
> > I just saw this bug report: https://bugs.php.net/bug.php?id=47038,
> > but it was closed with nothing explained.
>
> This bug report was closed because the bug it describes was fixed. It is
> explained so right on the bug page.
>
> > the php version I used:
> >
> > php --version
> > PHP 5.3.6-13ubuntu3.9 with Suhosin-Patch (cli) (built: Sep 12 2012
> 19:00:27)
> > Copyright (c) 1997-2011 The PHP Group
> > Zend Engine v2.3.0, Copyright (c) 1998-2011 Zend Technologies
>
> If you see the memory leak with current version (5.4.15/5.3.25) please
> submit a bug report containing the reproduction script and what happens
> when you run it. See the guidelines here:
> https://bugs.php.net/how-to-report.php
>
>
> --
> Stanislav Malyshev, Software Architect
> SugarCRM: http://www.sugarcrm.com/
> (408)454-6900 ext. 227
>

Re: [PHP-DEV] Memory leak in include()/require() ?

[Peter Wang]

I didn't find the history comments of that bug, now I see it, anyway,
thanks a lot, sorry for the noise.


On Thu, May 16, 2013 at 11:40 AM, Stas Malyshev wrote:

> Hi!
>
> > hi, did anyone come across the memory leak of require()/include(),
> > I just saw this bug report: https://bugs.php.net/bug.php?id=47038,
> > but it was closed with nothing explained.
>
> This bug report was closed because the bug it describes was fixed. It is
> explained so right on the bug page.
>
> > the php version I used:
> >
> > php --version
> > PHP 5.3.6-13ubuntu3.9 with Suhosin-Patch (cli) (built: Sep 12 2012
> 19:00:27)
> > Copyright (c) 1997-2011 The PHP Group
> > Zend Engine v2.3.0, Copyright (c) 1998-2011 Zend Technologies
>
> If you see the memory leak with current version (5.4.15/5.3.25) please
> submit a bug report containing the reproduction script and what happens
> when you run it. See the guidelines here:
> https://bugs.php.net/how-to-report.php
>
>
> --
> Stanislav Malyshev, Software Architect
> SugarCRM: http://www.sugarcrm.com/
> (408)454-6900 ext. 227
>

Re: [PHP-DEV] Memory leak in include()/require() ?

[Stas Malyshev]

Hi!

> hi, did anyone come across the memory leak of require()/include(),
> I just saw this bug report: https://bugs.php.net/bug.php?id=47038, 
> but it was closed with nothing explained.

This bug report was closed because the bug it describes was fixed. It is
explained so right on the bug page.

> the php version I used:
> 
> php --version
> PHP 5.3.6-13ubuntu3.9 with Suhosin-Patch (cli) (built: Sep 12 2012 19:00:27)
> Copyright (c) 1997-2011 The PHP Group
> Zend Engine v2.3.0, Copyright (c) 1998-2011 Zend Technologies

If you see the memory leak with current version (5.4.15/5.3.25) please
submit a bug report containing the reproduction script and what happens
when you run it. See the guidelines here:
https://bugs.php.net/how-to-report.php


-- 
Stanislav Malyshev, Software Architect
SugarCRM: http://www.sugarcrm.com/
(408)454-6900 ext. 227

-- 
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

[PHP-DEV] Memory leak in include()/require() ?

[peter wang]

hi, did anyone come across the memory leak of require()/include(),
I just saw this bug report: https://bugs.php.net/bug.php?id=47038, 
but it was closed with nothing explained.


the php version I used:

php --version
PHP 5.3.6-13ubuntu3.9 with Suhosin-Patch (cli) (built: Sep 12 2012 19:00:27)
Copyright (c) 1997-2011 The PHP Group
Zend Engine v2.3.0, Copyright (c) 1998-2011 Zend Technologies




-- 
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] Memory leak after calling exit() when Zend MM is turned off?

[Zeev Suraski]

On 16 בינו 2013, at 22:00, Pascal Mathis  wrote:

> Hi internals!
>
> I am currently developing a Zend extension. Because the Zend MM leak reports 
> are not really useful sometimes, I switched the memory manager off with the 
> environment variable USE_ZEND_ALLOC=0, so that I can use valgrind.
>
> Right now I have found some kind of memory leak. You can use every script 
> which has an exit()-call to reproduce this leak. For example:
>
> 
>
> If you run this PHP script with valgrind, it will report some ugly memory 
> leak:
>
> valgrind version: valgrind-3.6.0.SVN-Debian
> PHP Version: 5.4.10 (debug)
> Configure options: --disable-all --disable-cgi --enable-debug
> ---
> Command: export USE_ZEND_ALLOC=0 && valgrind --leak-check=full 
> php-5.4.10-debug test.php
> ---
> Report:
> ==5693== HEAP SUMMARY:
> ==5693== in use at exit: 420 bytes in 4 blocks
> ==5693==   total heap usage: 8,355 allocs, 8,351 frees, 2,503,705 bytes 
> allocated
> ==5693==
> ==5693== 420 (240 direct, 180 indirect) bytes in 1 blocks are definitely lost 
> in loss record 4 of
> ==5693==at 0x4C244E8: malloc (vg_replace_malloc.c:236)
> ==5693==by 0x5E08C4: _emalloc (zend_alloc.c:2423)
> ==5693==by 0x5C11C3: compile_file (zend_language_scanner.l:551)
> ==5693==by 0x617311: zend_execute_scripts (zend.c:1301)
> ==5693==by 0x58A22F: php_execute_script (main.c:2482)
> ==5693==by 0x768967: do_cli (php_cli.c:988)
> ==5693==by 0x76987C: main (php_cli.c:1364)
> ==5693==
> ==5693== LEAK SUMMARY:
> ==5693==definitely lost: 240 bytes in 1 blocks
> ==5693==indirectly lost: 180 bytes in 3 blocks
> ==5693==  possibly lost: 0 bytes in 0 blocks
> ==5693==still reachable: 0 bytes in 0 blocks
> ==5693== suppressed: 0 bytes in 0 blocks
>
> When the Zend memory manager is turned on, everything is fine. Is this 
> behavior intended?


Yes.  The implementation of exit() will not necessarily free all
allocated blocks.  It therefore intentionally suppresses errors that
might come from the memory manager regarding leaks - but if you turn
off the memory manager and use valgrind - you'd see them.  It's not a
problem unless you actually use PHP without the memory manager in
production, which of course you should not.

Zeev

--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] Memory leak after calling exit() when Zend MM is turned off?

[Rasmus Lerdorf]

On 01/16/2013 02:53 PM, Pascal Mathis wrote:

> When the Zend memory manager is turned on, everything is fine. Is this
> behavior intended?

We do have some intentional leaks where we rely on the pool allocator to
wipe things at the end of a request. So I am less concerned about things
you see at request termination than I would be if you found one mid-request.

-Rasmus

-- 
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

[PHP-DEV] Memory leak after calling exit() when Zend MM is turned off?

[Pascal Mathis]

Hi internals!

I am currently developing a Zend extension. Because the Zend MM leak 
reports are not really useful sometimes, I switched the memory manager 
off with the environment variable USE_ZEND_ALLOC=0, so that I can use 
valgrind.


Right now I have found some kind of memory leak. You can use every 
script which has an exit()-call to reproduce this leak. For example:




If you run this PHP script with valgrind, it will report some ugly 
memory leak:


valgrind version: valgrind-3.6.0.SVN-Debian
PHP Version: 5.4.10 (debug)
Configure options: --disable-all --disable-cgi --enable-debug
---
Command: export USE_ZEND_ALLOC=0 && valgrind --leak-check=full 
php-5.4.10-debug test.php

---
Report:
==5693== HEAP SUMMARY:
==5693== in use at exit: 420 bytes in 4 blocks
==5693==   total heap usage: 8,355 allocs, 8,351 frees, 2,503,705 bytes 
allocated

==5693==
==5693== 420 (240 direct, 180 indirect) bytes in 1 blocks are definitely 
lost in loss record 4 of

==5693==at 0x4C244E8: malloc (vg_replace_malloc.c:236)
==5693==by 0x5E08C4: _emalloc (zend_alloc.c:2423)
==5693==by 0x5C11C3: compile_file (zend_language_scanner.l:551)
==5693==by 0x617311: zend_execute_scripts (zend.c:1301)
==5693==by 0x58A22F: php_execute_script (main.c:2482)
==5693==by 0x768967: do_cli (php_cli.c:988)
==5693==by 0x76987C: main (php_cli.c:1364)
==5693==
==5693== LEAK SUMMARY:
==5693==definitely lost: 240 bytes in 1 blocks
==5693==indirectly lost: 180 bytes in 3 blocks
==5693==  possibly lost: 0 bytes in 0 blocks
==5693==still reachable: 0 bytes in 0 blocks
==5693== suppressed: 0 bytes in 0 blocks

When the Zend memory manager is turned on, everything is fine. Is this 
behavior intended?


Thanks in advance,
Pascal

--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] Memory Leak in ob_get_clean() / ob_get_flush ()

[Kalle Sommer Nielsen]

Hi Christian

2009/3/25 Christian Seiler :
> Hi Lukas,
>
>> Did this get addressed yet?
>
> No, it didn't. But since no one complained about it I'll commit it later
> this evening. (commit freeze is over, right?)

Yes commit freeze is over, RC1 was tagged in CVS the other day and
released yesterday.

>
> Regards,
> Christian
>
>



-- 
Kalle Sommer Nielsen
ka...@php.net

-- 
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] Memory Leak in ob_get_clean() / ob_get_flush ()

[Christian Seiler]

Hi Lukas,

> Did this get addressed yet?

No, it didn't. But since no one complained about it I'll commit it later
this evening. (commit freeze is over, right?)

Regards,
Christian


-- 
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] Memory Leak in ob_get_clean() / ob_get_flush ()

[Lukas Kahwe Smith]

Hi,

Did this get addressed yet?

regards,
Lukas

On 18.03.2009, at 03:15, Christian Seiler wrote:


Hi,

When running 'make test' on my system I discovered that
tests/output/ob_start_basic_unerasable_003.phpt and
tests/output/ob_start_basic_unerasable_004.phpt produced memory  
leaks -

due to the fact that they first fetch the buffer into return_value but
then do RETURN_FALSE if they detect an error and thus leak the copied
buffer.

I attached a patch that fixes that to this mail.

Any objections to me applying this for 5.3 and HEAD? (after 5.3 RC1  
when
commits are allowed again of course) Any side-effects I didn't think  
about?


Regards,
Christian
Index: main/output.c
===
RCS file: /repository/php-src/main/output.c,v
retrieving revision 1.167.2.3.2.4.2.12
diff -u -p -r1.167.2.3.2.4.2.12 output.c
--- main/output.c   13 Feb 2009 11:48:17 -  1.167.2.3.2.4.2.12
+++ main/output.c   18 Mar 2009 02:09:13 -
@@ -867,10 +867,12 @@ PHP_FUNCTION(ob_get_flush)
/* error checks */
if (!OG(ob_nesting_level)) {
		php_error_docref("ref.outcontrol" TSRMLS_CC, E_NOTICE, "failed to  
delete and flush buffer. No buffer to delete or flush.");

+   zval_dtor(return_value);
RETURN_FALSE;
}
	if (OG(ob_nesting_level) && !OG(active_ob_buffer).status && ! 
OG(active_ob_buffer).erase) {
		php_error_docref("ref.outcontrol" TSRMLS_CC, E_NOTICE, "failed to  
delete buffer %s.", OG(active_ob_buffer).handler_name);

+   zval_dtor(return_value);
RETURN_FALSE;
}
/* flush */
@@ -892,10 +894,12 @@ PHP_FUNCTION(ob_get_clean)
/* error checks */
if (!OG(ob_nesting_level)) {
		php_error_docref("ref.outcontrol" TSRMLS_CC, E_NOTICE, "failed to  
delete buffer. No buffer to delete.");

+   zval_dtor(return_value);
RETURN_FALSE;
}
	if (OG(ob_nesting_level) && !OG(active_ob_buffer).status && ! 
OG(active_ob_buffer).erase) {
		php_error_docref("ref.outcontrol" TSRMLS_CC, E_NOTICE, "failed to  
delete buffer %s.", OG(active_ob_buffer).handler_name);

+   zval_dtor(return_value);
RETURN_FALSE;
}
/* delete buffer */
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php


Lukas Kahwe Smith
m...@pooteeweet.org




--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

[PHP-DEV] Memory Leak in ob_get_clean() / ob_get_flush ()

[Christian Seiler]

Hi,

When running 'make test' on my system I discovered that
tests/output/ob_start_basic_unerasable_003.phpt and
tests/output/ob_start_basic_unerasable_004.phpt produced memory leaks -
due to the fact that they first fetch the buffer into return_value but
then do RETURN_FALSE if they detect an error and thus leak the copied
buffer.

I attached a patch that fixes that to this mail.

Any objections to me applying this for 5.3 and HEAD? (after 5.3 RC1 when
commits are allowed again of course) Any side-effects I didn't think about?

Regards,
Christian
Index: main/output.c
===
RCS file: /repository/php-src/main/output.c,v
retrieving revision 1.167.2.3.2.4.2.12
diff -u -p -r1.167.2.3.2.4.2.12 output.c
--- main/output.c   13 Feb 2009 11:48:17 -  1.167.2.3.2.4.2.12
+++ main/output.c   18 Mar 2009 02:09:13 -
@@ -867,10 +867,12 @@ PHP_FUNCTION(ob_get_flush)
/* error checks */
if (!OG(ob_nesting_level)) {
php_error_docref("ref.outcontrol" TSRMLS_CC, E_NOTICE, "failed 
to delete and flush buffer. No buffer to delete or flush.");
+   zval_dtor(return_value);
RETURN_FALSE;
}
if (OG(ob_nesting_level) && !OG(active_ob_buffer).status && 
!OG(active_ob_buffer).erase) {
php_error_docref("ref.outcontrol" TSRMLS_CC, E_NOTICE, "failed 
to delete buffer %s.", OG(active_ob_buffer).handler_name);
+   zval_dtor(return_value);
RETURN_FALSE;
}
/* flush */
@@ -892,10 +894,12 @@ PHP_FUNCTION(ob_get_clean)
/* error checks */
if (!OG(ob_nesting_level)) {
php_error_docref("ref.outcontrol" TSRMLS_CC, E_NOTICE, "failed 
to delete buffer. No buffer to delete.");
+   zval_dtor(return_value);
RETURN_FALSE;
}
if (OG(ob_nesting_level) && !OG(active_ob_buffer).status && 
!OG(active_ob_buffer).erase) {
php_error_docref("ref.outcontrol" TSRMLS_CC, E_NOTICE, "failed 
to delete buffer %s.", OG(active_ob_buffer).handler_name);
+   zval_dtor(return_value);
RETURN_FALSE;
}
/* delete buffer */
-- 
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] Memory leak per request in apache2filter PHP+ZTS(reposting third time)

[Kamesh Jayachandran]

Can Someone respond to this?
 
With regards
Kamesh Jayachandran

On Thu, 02 Dec 2004 06:27:32 -0800, "Kamesh Jayachandran"
<[EMAIL PROTECTED]> said:
> Can Someone respond to this?
> 
> With regards
> Kamesh Jayachandran
> On Mon, 29 Nov 2004 23:56:13 -0800, "Kamesh Jayachandran"
> <[EMAIL PROTECTED]> said:
> > Hi All,
> > I could see a leak of 60 bytes for the following script.
> >  > //echo "hi";
> > ?>
> > While investigation I found that 
> > SG(request_info).path_translated = safe_strdup(f->r->filename); 
> > //in sapi/apache2filter/sapi_apache2.c:php_apache_request_ctor
> > is not getting freed.
> > 
> > Can I free the same in php_apache_request_dtor?
> > 
> > I could see the above safe_strdup in sapi_apache2.c,v 1.108 on
> > 2003/04/10 11:28:54 by stas.
> > 
> > With regards
> > Kamesh Jayachandran
> > 
> > -- 
> > PHP Internals - PHP Runtime Development Mailing List
> > To unsubscribe, visit: http://www.php.net/unsub.php
> > 

-- 
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] Memory leak per request in apache2filter PHP+ZTS

[Kamesh Jayachandran]

Can Someone respond to this?

With regards
Kamesh Jayachandran
On Mon, 29 Nov 2004 23:56:13 -0800, "Kamesh Jayachandran"
<[EMAIL PROTECTED]> said:
> Hi All,
> I could see a leak of 60 bytes for the following script.
>  //echo "hi";
> ?>
> While investigation I found that 
>   SG(request_info).path_translated = safe_strdup(f->r->filename); 
> //in sapi/apache2filter/sapi_apache2.c:php_apache_request_ctor
> is not getting freed.
> 
> Can I free the same in php_apache_request_dtor?
> 
> I could see the above safe_strdup in sapi_apache2.c,v 1.108 on
> 2003/04/10 11:28:54 by stas.
> 
> With regards
> Kamesh Jayachandran
> 
> -- 
> PHP Internals - PHP Runtime Development Mailing List
> To unsubscribe, visit: http://www.php.net/unsub.php
> 

-- 
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

[PHP-DEV] Memory leak per request in apache2filter PHP+ZTS

[Kamesh Jayachandran]

Hi All,
I could see a leak of 60 bytes for the following script.

While investigation I found that 
SG(request_info).path_translated = safe_strdup(f->r->filename); 
//in sapi/apache2filter/sapi_apache2.c:php_apache_request_ctor
is not getting freed.

Can I free the same in php_apache_request_dtor?

I could see the above safe_strdup in sapi_apache2.c,v 1.108 on
2003/04/10 11:28:54 by stas.

With regards
Kamesh Jayachandran

-- 
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

[PHP-DEV] Memory leak debugging

[Curt Zirzow]

Is there prefered/suggested method on debugging memory leaks?

For example:

  $i = 100;
  while($i-- ) {
  list($foo['a']) = array('bar');
  }

Results with:

Zend/zend_execute.c(3383) :  Freeing 0x0840E1CC (4 bytes),
script=t.php
Zend/zend_variables.c(137) : Actual location (location was relayed)
Last leak repeated 99 times
Zend/zend_execute.c(3380) :  Freeing 0x0840E188 (16 bytes),
script=t.php
Last leak repeated 99 times
=== Total 200 memory leaks detected ===





Curt
-- 
First, let me assure you that this is not one of those shady pyramid schemes
you've been hearing about.  No, sir.  Our model is the trapezoid!

-- 
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] Memory leak

[Adam Maccabee Trachtenberg]

On Fri, 23 Jul 2004, George Schlossnagle wrote:

> Sterling's not as tough as he looks.

That's easy to say when you're 3,000 miles across the country.

Then again, I know you're going to be together in Portland next week,
so there's something for me to look forward to. :)

-adam

-- 
[EMAIL PROTECTED]
author of o'reilly's "upgrading to php 5" and "php cookbook"
avoid the holiday rush, buy your copies today!

-- 
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] Memory leak

[George Schlossnagle]

Sterling's not as tough as he looks.
On Jul 23, 2004, at 5:05 PM, Ilia Alshanetsky wrote:
Fine fine... let's rever it... I don't feel like carrying brass 
knuckles with
me all the time.

Ilia
On July 23, 2004 04:36 pm, Andi Gutmans wrote:
:)
Ilia, you heard the man. I don't think he leaves you much choice 
unless you
want to risk him waiting for you in a dark alley with a surprise :)

Andi
At 01:09 PM 7/23/2004 -0700, Sterling Hughes wrote:
dooalocaaa, 
damnit

On Fri, 23 Jul 2004 09:54:27 -0700, Andi Gutmans <[EMAIL PROTECTED]> 
wrote:
At 12:51 PM 7/23/2004 -0400, Ilia Alshanetsky wrote:
On July 23, 2004 12:40 pm, you wrote:
At 11:54 AM 7/23/2004 -0400, Ilia Alshanetsky wrote:
On July 23, 2004 11:42 am, Andi Gutmans wrote:
Why do we need one extra byte?
We do not.
Anyway, the question is if we should return to alloca() or not.
I am
slightly in favor but don't feel very strongly about it.
Perhaps we could try a combination of the two, to ensure that no
script is
terminated due to a PHP crash if allocating on the stack fails. 
By
default
we can use alloca() if that fails to allocate the memory, we
could use
emalloc() and set a flag free code indicating which free function
should
be used.
I'm hesitant to slow down the general case (even if it's just an
additional
if()) statement. I'd revert to alloca() and we can always add a
--paranoid-stack-allocation directive to configure to use 
emalloc()
:)
The problem is that that this causes certain large script to just
crash, without any meaningful information. Is the cost of 2 if()s
really that pefromance prohibitive?
No it's not. But 2 and 2 and 2 is :)
I guess we can go with the if()'s for now Argh...
Want to write a patch?

Andi
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
--
..II..
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] Memory leak

[Ilia Alshanetsky]

Fine fine... let's rever it... I don't feel like carrying brass knuckles with 
me all the time.

Ilia

On July 23, 2004 04:36 pm, Andi Gutmans wrote:
> :)
>
> Ilia, you heard the man. I don't think he leaves you much choice unless you
> want to risk him waiting for you in a dark alley with a surprise :)
>
> Andi
>
> At 01:09 PM 7/23/2004 -0700, Sterling Hughes wrote:
> >dooalocaaa, damnit
> >
> >On Fri, 23 Jul 2004 09:54:27 -0700, Andi Gutmans <[EMAIL PROTECTED]> wrote:
> > > At 12:51 PM 7/23/2004 -0400, Ilia Alshanetsky wrote:
> > > >On July 23, 2004 12:40 pm, you wrote:
> > > > > At 11:54 AM 7/23/2004 -0400, Ilia Alshanetsky wrote:
> > > > > >On July 23, 2004 11:42 am, Andi Gutmans wrote:
> > > > > > > Why do we need one extra byte?
> > > > > >
> > > > > >We do not.
> > > > > >
> > > > > > > Anyway, the question is if we should return to alloca() or not.
> >
> > I am
> >
> > > > > > > slightly in favor but don't feel very strongly about it.
> > > > > >
> > > > > >Perhaps we could try a combination of the two, to ensure that no
> >
> > script is
> >
> > > > > >terminated due to a PHP crash if allocating on the stack fails. By
> >
> > default
> >
> > > > > > we can use alloca() if that fails to allocate the memory, we
> >
> > could use
> >
> > > > > > emalloc() and set a flag free code indicating which free function
> >
> > should
> >
> > > > > > be used.
> > > > >
> > > > > I'm hesitant to slow down the general case (even if it's just an
> >
> > additional
> >
> > > > > if()) statement. I'd revert to alloca() and we can always add a
> > > > > --paranoid-stack-allocation directive to configure to use emalloc()
> > > > > :)
> > > >
> > > >The problem is that that this causes certain large script to just
> > > > crash, without any meaningful information. Is the cost of 2 if()s
> > > > really that pefromance prohibitive?
> > >
> > > No it's not. But 2 and 2 and 2 is :)
> > > I guess we can go with the if()'s for now Argh...
> > > Want to write a patch?
> > >
> > >
> > >
> > > Andi
> > >
> > > --
> > > PHP Internals - PHP Runtime Development Mailing List
> > > To unsubscribe, visit: http://www.php.net/unsub.php
> >
> >--
> >..II..

-- 
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] Memory leak

[Andi Gutmans]

:)
Ilia, you heard the man. I don't think he leaves you much choice unless you 
want to risk him waiting for you in a dark alley with a surprise :)

Andi
At 01:09 PM 7/23/2004 -0700, Sterling Hughes wrote:
dooalocaaa, damnit
On Fri, 23 Jul 2004 09:54:27 -0700, Andi Gutmans <[EMAIL PROTECTED]> wrote:
> At 12:51 PM 7/23/2004 -0400, Ilia Alshanetsky wrote:
> >On July 23, 2004 12:40 pm, you wrote:
> > > At 11:54 AM 7/23/2004 -0400, Ilia Alshanetsky wrote:
> > > >On July 23, 2004 11:42 am, Andi Gutmans wrote:
> > > > > Why do we need one extra byte?
> > > >
> > > >We do not.
> > > >
> > > > > Anyway, the question is if we should return to alloca() or not. 
I am
> > > > > slightly in favor but don't feel very strongly about it.
> > > >
> > > >Perhaps we could try a combination of the two, to ensure that no 
script is
> > > >terminated due to a PHP crash if allocating on the stack fails. By 
default
> > > > we can use alloca() if that fails to allocate the memory, we 
could use
> > > > emalloc() and set a flag free code indicating which free function 
should
> > > > be used.
> > >
> > > I'm hesitant to slow down the general case (even if it's just an 
additional
> > > if()) statement. I'd revert to alloca() and we can always add a
> > > --paranoid-stack-allocation directive to configure to use emalloc() :)
> >
> >The problem is that that this causes certain large script to just crash,
> >without any meaningful information. Is the cost of 2 if()s really that
> >pefromance prohibitive?
>
> No it's not. But 2 and 2 and 2 is :)
> I guess we can go with the if()'s for now Argh...
> Want to write a patch?
>
>
>
> Andi
>
> --
> PHP Internals - PHP Runtime Development Mailing List
> To unsubscribe, visit: http://www.php.net/unsub.php
>
>

--
..II..
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] Memory leak

[Sterling Hughes]

dooalocaaa, damnit

On Fri, 23 Jul 2004 09:54:27 -0700, Andi Gutmans <[EMAIL PROTECTED]> wrote:
> At 12:51 PM 7/23/2004 -0400, Ilia Alshanetsky wrote:
> >On July 23, 2004 12:40 pm, you wrote:
> > > At 11:54 AM 7/23/2004 -0400, Ilia Alshanetsky wrote:
> > > >On July 23, 2004 11:42 am, Andi Gutmans wrote:
> > > > > Why do we need one extra byte?
> > > >
> > > >We do not.
> > > >
> > > > > Anyway, the question is if we should return to alloca() or not. I am
> > > > > slightly in favor but don't feel very strongly about it.
> > > >
> > > >Perhaps we could try a combination of the two, to ensure that no script is
> > > >terminated due to a PHP crash if allocating on the stack fails. By default
> > > > we can use alloca() if that fails to allocate the memory, we could use
> > > > emalloc() and set a flag free code indicating which free function should
> > > > be used.
> > >
> > > I'm hesitant to slow down the general case (even if it's just an additional
> > > if()) statement. I'd revert to alloca() and we can always add a
> > > --paranoid-stack-allocation directive to configure to use emalloc() :)
> >
> >The problem is that that this causes certain large script to just crash,
> >without any meaningful information. Is the cost of 2 if()s really that
> >pefromance prohibitive?
> 
> No it's not. But 2 and 2 and 2 is :)
> I guess we can go with the if()'s for now Argh...
> Want to write a patch?
> 
> 
> 
> Andi
> 
> --
> PHP Internals - PHP Runtime Development Mailing List
> To unsubscribe, visit: http://www.php.net/unsub.php
> 
> 


-- 
..II..

-- 
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] Memory leak

[Lukas Smith]

message from marcus börger:
"I have fixed the problem, without the need for an additional byte"
regards,
Lukas Smith aka Proxy
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] Memory leak

[Andi Gutmans]

At 12:51 PM 7/23/2004 -0400, Ilia Alshanetsky wrote:
On July 23, 2004 12:40 pm, you wrote:
> At 11:54 AM 7/23/2004 -0400, Ilia Alshanetsky wrote:
> >On July 23, 2004 11:42 am, Andi Gutmans wrote:
> > > Why do we need one extra byte?
> >
> >We do not.
> >
> > > Anyway, the question is if we should return to alloca() or not. I am
> > > slightly in favor but don't feel very strongly about it.
> >
> >Perhaps we could try a combination of the two, to ensure that no script is
> >terminated due to a PHP crash if allocating on the stack fails. By default
> > we can use alloca() if that fails to allocate the memory, we could use
> > emalloc() and set a flag free code indicating which free function should
> > be used.
>
> I'm hesitant to slow down the general case (even if it's just an additional
> if()) statement. I'd revert to alloca() and we can always add a
> --paranoid-stack-allocation directive to configure to use emalloc() :)
The problem is that that this causes certain large script to just crash,
without any meaningful information. Is the cost of 2 if()s really that
pefromance prohibitive?
No it's not. But 2 and 2 and 2 is :)
I guess we can go with the if()'s for now Argh...
Want to write a patch?
Andi
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] Memory leak

[Ilia Alshanetsky]

On July 23, 2004 12:40 pm, you wrote:
> At 11:54 AM 7/23/2004 -0400, Ilia Alshanetsky wrote:
> >On July 23, 2004 11:42 am, Andi Gutmans wrote:
> > > Why do we need one extra byte?
> >
> >We do not.
> >
> > > Anyway, the question is if we should return to alloca() or not. I am
> > > slightly in favor but don't feel very strongly about it.
> >
> >Perhaps we could try a combination of the two, to ensure that no script is
> >terminated due to a PHP crash if allocating on the stack fails. By default
> > we can use alloca() if that fails to allocate the memory, we could use
> > emalloc() and set a flag free code indicating which free function should
> > be used.
>
> I'm hesitant to slow down the general case (even if it's just an additional
> if()) statement. I'd revert to alloca() and we can always add a
> --paranoid-stack-allocation directive to configure to use emalloc() :)

The problem is that that this causes certain large script to just crash, 
without any meaningful information. Is the cost of 2 if()s really that 
pefromance prohibitive?

Ilia

-- 
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] Memory leak

[Andi Gutmans]

At 11:54 AM 7/23/2004 -0400, Ilia Alshanetsky wrote:
On July 23, 2004 11:42 am, Andi Gutmans wrote:
> Why do we need one extra byte?
We do not.
> Anyway, the question is if we should return to alloca() or not. I am
> slightly in favor but don't feel very strongly about it.
Perhaps we could try a combination of the two, to ensure that no script is
terminated due to a PHP crash if allocating on the stack fails. By default we
can use alloca() if that fails to allocate the memory, we could use emalloc()
and set a flag free code indicating which free function should be used.
I'm hesitant to slow down the general case (even if it's just an additional 
if()) statement. I'd revert to alloca() and we can always add a 
--paranoid-stack-allocation directive to configure to use emalloc() :)

Andi
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] Memory leak

[Ilia Alshanetsky]

On July 23, 2004 11:42 am, Andi Gutmans wrote:
> Why do we need one extra byte?

We do not.

> Anyway, the question is if we should return to alloca() or not. I am
> slightly in favor but don't feel very strongly about it.

Perhaps we could try a combination of the two, to ensure that no script is 
terminated due to a PHP crash if allocating on the stack fails. By default we 
can use alloca() if that fails to allocate the memory, we could use emalloc() 
and set a flag free code indicating which free function should be used.

Ilia

-- 
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] Memory leak

[Andi Gutmans]

Why do we need one extra byte?
Anyway, the question is if we should return to alloca() or not. I am 
slightly in favor but don't feel very strongly about it.

Andi
At 08:44 AM 7/23/2004 +0200, Marcus Boerger wrote:
Hello Andi,
the easiest way to make the test suit for 5.1 work again is to
change zend_execute.c line 1352 to:
EX(Ts) = (temp_variable *) safe_emalloc(sizeof(temp_variable), 
op_array->T, 1);

notice the 1 instead of 0 which allocates one additional byte for every
execution.
regards
marcus
Thursday, July 22, 2004, 11:25:57 PM, you wrote:
> The executor() change from alloca() to emalloc() seems to have introduced a
> memory leak (found it with --enable-debug). Before I try and fix it, are we
> reverting back to do_alloca(), free_alloca()? (even though we should see
> why this memory leak is happening anyway because we don't always use
> alloca() for do_allocat()).
> Andi

--
Best regards,
 Marcusmailto:[EMAIL PROTECTED]
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] Memory leak

[Marcus Boerger]

Hello Andi,

the easiest way to make the test suit for 5.1 work again is to
change zend_execute.c line 1352 to:
EX(Ts) = (temp_variable *) safe_emalloc(sizeof(temp_variable), op_array->T, 1);

notice the 1 instead of 0 which allocates one additional byte for every
execution.

regards
marcus

Thursday, July 22, 2004, 11:25:57 PM, you wrote:

> The executor() change from alloca() to emalloc() seems to have introduced a
> memory leak (found it with --enable-debug). Before I try and fix it, are we
> reverting back to do_alloca(), free_alloca()? (even though we should see 
> why this memory leak is happening anyway because we don't always use 
> alloca() for do_allocat()).

> Andi




-- 
Best regards,
 Marcusmailto:[EMAIL PROTECTED]

-- 
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

[PHP-DEV] Memory leak

[Andi Gutmans]

The executor() change from alloca() to emalloc() seems to have introduced a 
memory leak (found it with --enable-debug). Before I try and fix it, are we 
reverting back to do_alloca(), free_alloca()? (even though we should see 
why this memory leak is happening anyway because we don't always use 
alloca() for do_allocat()).

Andi
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] Memory leak with .=

[Timm Friebe]

On Tue, 2004-03-02 at 11:13, Andi Gutmans wrote:
> Fixed.

Verified.

> Thanks for the reproducing case.

You're welcome:)

- Timm

-- 
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] Memory leak with .=

[Andi Gutmans]

Fixed.
Thanks for the reproducing case.
At 11:25 PM 2/27/2004 +0100, Timm Friebe wrote:
The following script:


public function append($string) {
  $this->buf.= ($string instanceof StringBuffer
? $string->buf
: $string
  );
}
  }
  $s= new StringBuffer();
  $s->append('Hello');
?>
causes:

/usr/home/thekid/devel/php/php/Zend/zend_execute.c(4049) :  Freeing
0x083B0310 (6 bytes), script=string.php
/usr/home/thekid/devel/php/php/Zend/zend_variables.c(137) : Actual
location (location was relayed)
=== Total 1 memory leaks detected ===
Changing the line $this->buf.= [...] to $this->buf= $this->buf. makes
the leak disappear.
- Timm

--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

[PHP-DEV] Memory leak with .=

[Timm Friebe]

The following script:

buf.= ($string instanceof StringBuffer
? $string->buf
: $string
  );
}
  }
  
  $s= new StringBuffer();
  $s->append('Hello');
?>

causes:

/usr/home/thekid/devel/php/php/Zend/zend_execute.c(4049) :  Freeing
0x083B0310 (6 bytes), script=string.php
/usr/home/thekid/devel/php/php/Zend/zend_variables.c(137) : Actual
location (location was relayed)
=== Total 1 memory leaks detected ===

Changing the line $this->buf.= [...] to $this->buf= $this->buf. makes
the leak disappear.

- Timm

-- 
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

[PHP-DEV] Memory leak in *printf

[Timm Friebe]

/usr/home/thekid/devel/php/php/ext/standard/formatted_print.c(625) : 
Freeing 0x085634A0 (16 bytes),
script=/home/thekid/experiments/examples/reflection.php
Last leak repeated 1 time
/usr/home/thekid/devel/php/php/ext/standard/formatted_print.c(627) : 
Freeing 0x083B2020 (59 bytes),
script=/home/thekid/experiments/examples/reflection.php
/usr/home/thekid/devel/php/php/Zend/zend_variables.c(137) : Actual
location (location was relayed)
=== Total 3 memory leaks detected ===

Don't have a simple script for this, either. Sorry.

- Timm

-- 
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php