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():
>
> Be
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
>
> 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
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
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
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
> 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
aturday, 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
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. C
> 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 =
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),
> > &g
> 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 &q
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
>
> 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
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
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
> 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),
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) {
>
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
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
Hi,
Thanks for your information.
I also tested the latest stable version of APC
(3.1.9http://pecl.php.net/package/APC/3.1.9),
which has the same problem.
On Fri, May 17, 2013 at 9:42 AM, Leigh lei...@gmail.com wrote:
I found that the memory leak is actually related to APC,
even with
More information about this bug:
To stably re-produce the bug, we need create 2 files.
// file1.php, can be empty
// leak.php
?php
while (true) {
$file = 'file1.php';
require($file);
}
then run: php -d apc.enable_cli=1 leak.php
hope this helps, thanks.
On Thu, May 16, 2013 at 1:25
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)
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.
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 smalys...@sugarcrm.comwrote:
Hi!
hi, did anyone come across the memory leak of require()/include(),
I just saw this bug report:
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
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.
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 smalys...@sugarcrm.comwrote:
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
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
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
On 16 בינו 2013, at 22:00, Pascal Mathis d...@snapserv.net 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
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
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
Hi Christian
2009/3/25 Christian Seiler chris...@gmx.net:
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
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
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
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.
?php
//echo hi;
?
While investigation I found that
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
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
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
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
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
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
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
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:
:)
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
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
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
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
Fixed.
Thanks for the reproducing case.
At 11:25 PM 2/27/2004 +0100, Timm Friebe wrote:
The following script:
?php
class StringBuffer {
public $buf= '';
public function append($string) {
$this-buf.= ($string instanceof StringBuffer
? $string-buf
: $string
);
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
The following script:
?php
class StringBuffer {
public $buf= '';
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/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),
53 matches
Mail list logo
