On Mon, 20 Feb 2017 06:39:32 -0800, ronaldxs wrote:
> jnthn mentioned on irc awareness of at least one more leak
> (presumably) related to this ticket and so ticket waits on news of
> fixing further leak(s).
Running the example above one a 32-bit Linux VM I get:
This Rakudo version is 2018.03.136
lease bear with me.
> > >
> > > Initial conversation and relatively golfed down code:
> > > https://irclog.perlgeek.de/moarvm/2017-08-05#i_14973432
> > > https://gist.github.com/MasterDuke17/685b627a6a2749483dc5ec09c6a777a4
> > >
> > > dogbert11++ repro
om/rakudo/rakudo .
>
> Thank you!
>
> > On 22 Jan 2018, at 01:24, David E. wrote:
> >
> > I'm not certain where to report this (ie: rakudo vs MoarVM), so I'm
> starting here.
> >
> > After some experimentation, I finally traced down a segfault I&#
(ie: rakudo vs MoarVM), so I'm starting
> here.
>
> After some experimentation, I finally traced down a segfault I've been
> getting to a memory leak in the NativeCall interface. I'm using it to
> facilitate testing of a 32-bit embedded (meaning no dynami
It looks like the String may not be at fault - changing the argument to an
int32 pointer results in the same memory leak. In either case, the
variable is allocated on the static in the C function and would be
automatically freed when the function returns, so the problem has to be
some temporary
19:24, David E. wrote:
>
> I'm not certain where to report this (ie: rakudo vs MoarVM), so I'm starting
> here.
>
> After some experimentation, I finally traced down a segfault I've been
> getting to a memory leak in the NativeCall interface. I'm using it to
I'm not certain where to report this (ie: rakudo vs MoarVM), so I'm
starting here.
After some experimentation, I finally traced down a segfault I've been
getting to a memory leak in the NativeCall interface. I'm using it to
facilitate testing of a 32-bit embedded (meaning n
/gist.github.com/MasterDuke17/685b627a6a2749483dc5ec09c6a777a4
> >
> > dogbert11++ reproducing the issue
> > https://irclog.perlgeek.de/moarvm/2017-08-06#i_14976177
> >
> > (note that it seems like there's no memory leak, but the memory usage
> > is gr
.com/MasterDuke17/685b627a6a2749483dc5ec09c6a777a4
>
> dogbert11++ reproducing the issue
> https://irclog.perlgeek.de/moarvm/2017-08-06#i_14976177
>
> (note that it seems like there's no memory leak, but the memory usage
> is growing)
>
> More: https://irclog.perlgeek.de/perl6/2
b.com/MasterDuke17/685b627a6a2749483dc5ec09c6a777a4
dogbert11++ reproducing the issue
https://irclog.perlgeek.de/moarvm/2017-08-06#i_14976177
(note that it seems like there's no memory leak, but the memory usage is
growing)
More: https://irclog.perlgeek.de/perl6/2017-08-08#i_14987204
I don't know if this aff
every run
which makes me further wonder why?
The numbers are also drastically different between my OSX and running
on Travis-CI, though Rakudo is also different.
Does any of this make sense? Does it indicate any memory leak in
Rakudo already or is this just normal memory usage?
How could I improve m
On Tue, 10 Jan 2017 14:30:27 -0800, ronaldxs wrote:
> Both code sample and htmlify.p6 still leak for me. Sorry.
>
Yes, I wasn't entirely clear - there was more than one issue, and so fixing the
first couple of issues only improved things rather than fully resolved them. I
just bumped MOAR_REVIS
On Tue, 03 Jan 2017 12:36:10 -0800, c...@zoffix.com wrote:
> On Tue, 03 Jan 2017 10:33:31 -0800, ronaldxs wrote:
> > Links:
> > --
> > [1] https://github.com/perl6/doc/issues/1104
> > [2]
> > https://github.com/perl6/Pod-To-
> > HTML/blob/master/lib/Pod/To/HTML.pm#L300
>
>
> Confirmed on Raku
On Tue, 03 Jan 2017 10:33:31 -0800, ronaldxs wrote:
> Links:
> --
> [1] https://github.com/perl6/doc/issues/1104
> [2]
> https://github.com/perl6/Pod-To-HTML/blob/master/lib/Pod/To/HTML.pm#L300
Confirmed on Rakudo version 2016.12-52-g9eed276 built on MoarVM version
2016.12-6-g65acd55 on runn
# New Ticket Created by Ron Schmidt
# Please include the string: [perl #130494]
# in the subject line of all future correspondence about this issue.
# https://rt.perl.org/Ticket/Display.html?id=130494 >
The example below is believed to be a simplification of memory leak
Issue #1104 [1]
I was able to reproduce the problem with rakudo 2016.01.1 on Linux.
It seems to be fixed now (maybe with rakudo commit 241e5e5847):
$ ls -lh 126372.data
-rw-r--r-- 2 christian christian 48M Apr 11 14:07 126372.data
$ time ./perl6-m -e 'my $content = slurp "126372.data", :bin; say
$content.elem
; "[BUG]memory leak slurp",
> a summary of which appears below.
>
> There is no need to reply to this message right now. Your ticket has been
> assigned an ID of [perl #127382].
>
> Please include the string:
>
> [perl #127382]
>
> in the sub
# New Ticket Created by dump array
# Please include the string: [perl #127382]
# in the subject line of all future correspondence about this issue.
# https://rt.perl.org/Ticket/Display.html?id=127382 >
i have 36M big sql file, this:
my $content = slurp 'file', :bin;
eats up all my computer
On Sat, Jan 10, 2015 at 10:25 PM, wrote:
>
>
> On 01/10/2015 08:39 PM, Gabor Szabo wrote:
> > Well, whatever it is, this means that the web application fills all
> > the memory and crashes every 30-40 requests.
> > Luckily there are not many people who read the site :)
> >
> > Gabor
> >
> >
>
> I'
On 01/10/2015 08:39 PM, Gabor Szabo wrote:
> Well, whatever it is, this means that the web application fills all
> the memory and crashes every 30-40 requests.
> Luckily there are not many people who read the site :)
>
> Gabor
>
>
I'm expecting you're talking about
https://github.com/szabgab/Per
ter just a few requests.
>
> A quick check seems to indicated that while-loops don't have the same
> memory leak,
> but before I run and rewrite every for loop into a while-loop, it would be
> nice to know
> if there are other parts of the language that are leaking memory?
>
&
ests.
>
> A quick check seems to indicated that while-loops don't have the same
> memory leak,
> but before I run and rewrite every for loop into a while-loop, it
> would be nice to know
> if there are other parts of the language that are leaking memory?
>
>
> regards
hout the internal $x variable, but my main
problem
is that this means the web application running the Perl6Maven.com site
fills the memory
after just a few requests.
A quick check seems to indicated that while-loops don't have the same
memory leak,
but before I run and rewrite every for loop
That happens because the result of the for statement is a list that is
then sunk; it contains one scalar and one Int object for each iteration
and rakudo doesn't yet know to throw it away immediately.
Regards
- Timo
I have Rakudo Start 2014.12.1 compiled with MoarVM running on OSX
and it seems to be leaking memory, but I need your help in confirming my
understanding:
I created this script to show it:
use v6;
sub MAIN(Int $count) {
prompt("Start");
for 1 .. $count -> $i {
my $x = 42;
}
As a status update: An empty EVAL combined with "while 1" still seems to
consume more and more memory (happens on Moar, Parrot and JVM):
$ perl6 -e 'EVAL q[] while 1'
On 12/19/2013 10:32 PM, Patrick R. Michaud wrote:
On Thu, Dec 19, 2013 at 11:27:32AM +0800, Richard Hainsworth wrote:
I've been running a perl6 program that runs through a loop, dumps
intermediate results and starts again with new initialisation
values.
[...]
Looking at system resources, the pro
On Thu, Dec 19, 2013 at 11:27:32AM +0800, Richard Hainsworth wrote:
> I've been running a perl6 program that runs through a loop, dumps
> intermediate results and starts again with new initialisation
> values.
> [...]
> Looking at system resources, the program chews up memory resources
> continuall
I've been running a perl6 program that runs through a loop, dumps
intermediate results and starts again with new initialisation values.
The program runs fine for the first three loops, but does appear to slow
down and on the fourth time though hangs.
Looking at system resources, the program c
On Thu Sep 02 08:37:25 2010, pmichaud wrote:
> On Thu, Sep 02, 2010 at 11:20:52AM -0400, Will Coleda wrote:
> > > Currently each eval() execution results in compiling and
> > > loading at least two additional Parrot subs into memory
> > > that represent the eval'ed code. �As far as I can tell,
> >
On Thu, Sep 02, 2010 at 11:20:52AM -0400, Will Coleda wrote:
> > Currently each eval() execution results in compiling and
> > loading at least two additional Parrot subs into memory
> > that represent the eval'ed code. As far as I can tell,
> > once loaded there's currently no way for a Parrot Sub
On Thu, Sep 2, 2010 at 10:35 AM, Patrick R. Michaud wrote:
> On Thu, Sep 02, 2010 at 03:02:43AM -0700, Paweł Pabian wrote:
>> Star 2010.08 release
>>
>> Run folloing code and it will start eating up memory quite fast.
>>
>> $ perl6 -e 'use Test; eval_lives_ok "" for 1..1'
>>
>> [11:59] eval '
On Thu, Sep 02, 2010 at 03:02:43AM -0700, Paweł Pabian wrote:
> Star 2010.08 release
>
> Run folloing code and it will start eating up memory quite fast.
>
> $ perl6 -e 'use Test; eval_lives_ok "" for 1..1'
>
> [11:59] eval '' while 1; also leaks
> [11:59] so I think it's eval() that leaks
# New Ticket Created by Paweł Pabian
# Please include the string: [perl #77644]
# in the subject line of all future correspondence about this issue.
# http://rt.perl.org/rt3/Ticket/Display.html?id=77644 >
Star 2010.08 release
Run folloing code and it will start eating up memory quite fast.
# New Ticket Created by Carlin Bingham
# Please include the string: [perl #70183]
# in the subject line of all future correspondence about this issue.
# http://rt.perl.org/rt3/Ticket/Display.html?id=70183 >
This did not occur in 657d55cce1f1ded33fd1f731344bd31b33099cb8 but is
present in 6b04b
# New Ticket Created by Will Coleda
# Please include the string: [perl #60540]
# in the subject line of all future correspondence about this issue.
# http://rt.perl.org/rt3/Ticket/Display.html?id=60540 >
This tcl code (a snippet from the official tcl test suite) runs out of
memory on partcl.
On Tue, Oct 21, 2008 at 6:00 PM, Andrew Whitworth via RT
<[EMAIL PROTECTED]> wrote:
> Is this still an issue? I've never even heard of the "PCCMETHOD
> Compiler", does it still exist? Is it used? Is FixedIntegerArray known
> to be leaking any memory?
The perl that translates METHOD calls (previous
On Tue Mar 27 09:42:00 2007, guest wrote:
> On Mon Mar 26 16:52:16 2007, [EMAIL PROTECTED] wrote:
> > Hi,
> >
> > The following PMC leaks memory at about 55Mb/100 calls to `call()'
> >
> > #include "parrot/parrot.h"
> >
> > static INTVAL dynpmc_Foo;
> >
> > pmclass Foo dynpmc {
> > void
Fixed in r31508
# New Ticket Created by chromatic
# Please include the string: [perl #50448]
# in the subject line of all future correspondence about this issue.
# http://rt.perl.org/rt3/Ticket/Display.html?id=50448 >
When an exception occurs and exits Parrot, some of the memory allocated by
IMCC can go unf
On Thursday 22 November 2007 20:33:19 Mark Glines wrote:
> > There is a memory leak with the STRING's. Next C code consumes more
> > and more memory, but does not free it:
> >
> > for(i=0;i<2000;i++) {
> > string_from_literal(INTERP, &q
this issue.
> # http://rt.perl.org/rt3/Ticket/Display.html?id=47704 >
>
>
> There is a memory leak with the STRING's. Next C code consumes more
> and more memory, but does not free it:
>
> for(i=0;i<2000;i++) {
> string_from_literal(INTERP, "nothi
# New Ticket Created by "Mehmet Yavuz Selim Soyturk"
# Please include the string: [perl #47704]
# in the subject line of all future correspondence about this issue.
# http://rt.perl.org/rt3/Ticket/Display.html?id=47704 >
There is a memory leak with the STRING's. Next C code
> I traced the context creation and freeing (parrot -D80) but everything there
> matched up, so I finally narrowed things down to the affected lines in
> PMCProxy. Your initial instinct was good, so nice catch and good test case.
Thanks. That suppressed the leak in my first test cases. But I thin
On Sunday 18 November 2007 09:48:30 Mehmet Yavuz Selim Soyturk wrote:
> I did not test it with Valgrind (I'm not sure how to use it), but I
> see increasing memory usage in the task manager.
>
> .sub _ :main
> loop:
>$P0 = new 'Integer'
>$P0 = 27
>$P1 = new 'PMCProxy', $P0
>goto lo
I think that the leak is at C.
I tested it that way:
test.pmc
#include "parrot/parrot.h"
pmclass Test
dynpmc
group pjs_group
hll Pjs {
void set_integer_native(INTVAL ignore) {
int i;
for(i=0;i<1000;i++) {
Parrot_PCCINVOKE(INTERP, SELF,
[Sorry chromatic, forgot to send to the list]
> Did you happen to catch which PMC it is that's leaking?
I don't know which PMC, but the leak happens when you create a
PMCProxy with init_pmc.
> Also, is this with PIR or PBC or both?
Both.
> Do you have a short test case that Valgrind catches?
On Sunday 18 November 2007 08:08:25 Mehmet Yavuz Selim Soyturk wrote:
> If you have defined an .HLL in your program, any pmc leaks. I could
> track the problem down to PMCProxy::init_pmc.
>
> If these lines of PMCProxy::init_pmc are removed, the leak disappears:
>
> if (!PMC_IS_NULL(proxy_
# New Ticket Created by "Mehmet Yavuz Selim Soyturk"
# Please include the string: [perl #47572]
# in the subject line of all future correspondence about this issue.
# http://rt.perl.org/rt3/Ticket/Display.html?id=47572 >
If you have defined an .HLL in your program, any pmc leaks. I could
trac
On Sunday 21 October 2007 10:54:16 Bram Geron wrote:
> chromatic wrote:
> > Seems reasonable to me. How did you check for leaks, by the way?
> I ran the test file for two minutes (it's an infinite loop), and top
> showed no change in memory use. I assumed that was accurate enough :)
Sounds rig
chromatic wrote:
> On Sunday 21 October 2007 07:57:58 Bram Geron wrote:
>
>> Attached patch fixes the segfault for me. (And no memory leak too.) The
>> problem was that mark_context didn't mark ctx->caller_ctx, which is used
>> in get_params. Usually the call
On Sunday 21 October 2007 07:57:58 Bram Geron wrote:
> Attached patch fixes the segfault for me. (And no memory leak too.) The
> problem was that mark_context didn't mark ctx->caller_ctx, which is used
> in get_params. Usually the caller context is accessible through
> curre
(gdb) p key->vtable
> $2 = (VTABLE *) 0xdeadbeef
> (gdb) p key->vtable->base_type
> Cannot access memory at address 0xdeadbef3
>
>
>
> --
> Will "Coke" Coleda
> [EMAIL PROTECTED]
>
>
>
Attached patch fixes the segfault for me. (And no memory lea
ops: open */
This occurs just before returning from the method. The memory leak needs
to be fixed.
# New Ticket Created by Paul Cochrane
# Please include the string: [perl #45991]
# in the subject line of all future correspondence about this issue.
# http://rt.perl.org/rt3/Ticket/Display.html?id=45991 >
In src/objects.c:Parrot_add_attribute() there is the todo item:
/* XXX leak! */
string
On Sep 10, 2007, at 12:47 AM, chromatic wrote:
On Sunday 09 September 2007 21:40:56 Will Coleda via RT wrote:
Program received signal EXC_BAD_ACCESS, Could not access memory.
Reason: KERN_INVALID_ADDRESS at address: 0xdeadbef3
0x00010b42 in clone_key_arg (interp=0x31003b0, st=0xbfffef3c) at
On Sunday 09 September 2007 21:40:56 Will Coleda via RT wrote:
>
> Program received signal EXC_BAD_ACCESS, Could not access memory.
> Reason: KERN_INVALID_ADDRESS at address: 0xdeadbef3
> 0x00010b42 in clone_key_arg (interp=0x31003b0, st=0xbfffef3c) at
> src/inter_call.c:641 641 if (key &&
On Sun Jun 03 20:33:35 2007, [EMAIL PROTECTED] wrote:
> On Saturday 28 April 2007 16:43:06 Mehmet Yavuz Selim Soyturk wrote:
>
> > Next program makes a slurpy tailcall, and it causes a memory leak
> for me.
>
> Confirmed. Interestingly, the problem looks like a Key
On Saturday 28 April 2007 16:43:06 Mehmet Yavuz Selim Soyturk wrote:
> Next program makes a slurpy tailcall, and it causes a memory leak for me.
Confirmed. Interestingly, the problem looks like a Key PMC somewhere gets
garbage collected inappropriately.
I tried various tricks to mark
# New Ticket Created by "Mehmet Yavuz Selim Soyturk"
# Please include the string: [perl #42790]
# in the subject line of all future correspondence about this issue.
# http://rt.perl.org/rt3/Ticket/Display.html?id=42790 >
Next program makes a slurpy tailcall, and it causes a me
Am Dienstag, 24. April 2007 07:45 schrieb chromatic:
> Here's my solution; don't allocate zero-sized buffers. Let them be empty.
Great catch. Thanks.
Indeed - zero-size allocs should just be ignored or/and even the source of
such requests be weeded out.
leo
.sub main :main
loop:
$P0 = new .String
goto loop
.end
This one's fun.
One punchline's in src/gc/resources.c:153, within mem_allocate().
If it looks like there's no reclaimable memory within the allocated arena
pools, there's no sense in compacting them to try to get enough memory to
On Monday 23 April 2007 16:41, Matt Diephouse wrote:
> Leopold Toetsch <[EMAIL PROTECTED]> wrote:
> > Am Montag, 23. April 2007 20:23 schrieb chromatic:
> > > > .sub main :main
> > > > loop:
> > > > $P0 = new .String
> > > > goto loop
> > > > .end
> >
> > That's an endless loop. How does
Leopold Toetsch <[EMAIL PROTECTED]> wrote:
Am Montag, 23. April 2007 20:23 schrieb chromatic:
> On Thursday 05 April 2007 16:56, Mehmet Yavuz Selim Soyturk wrote:
> > The next program causes a memory leak for me.
> >
> > .sub main :main
> > loop:
> >
Am Montag, 23. April 2007 20:23 schrieb chromatic:
> On Thursday 05 April 2007 16:56, Mehmet Yavuz Selim Soyturk wrote:
> > The next program causes a memory leak for me.
> >
> > .sub main :main
> > loop:
> > $P0 = new .String
> > goto loop
> &g
On Monday 23 April 2007 11:42, jerry gay wrote:
> > I don't guarantee that I've identified the appropriate code clearly
> > though; digging through this is tricky.
> > Does this sound familiar or interesting or fun to anyone else?
> sounds to me like it could be a reason for the pge garbage coll
On 4/23/07, chromatic <[EMAIL PROTECTED]> wrote:
On Thursday 05 April 2007 16:56, Mehmet Yavuz Selim Soyturk wrote:
> The next program causes a memory leak for me.
>
> .sub main :main
> loop:
> $P0 = new .String
> goto loop
> .end
>
>
> Interestingly
On Thursday 05 April 2007 16:56, Mehmet Yavuz Selim Soyturk wrote:
> The next program causes a memory leak for me.
>
> .sub main :main
> loop:
> $P0 = new .String
> goto loop
> .end
>
>
> Interestingly, no memory leak with:
>
> .sub main :main
> lo
# New Ticket Created by "Mehmet Yavuz Selim Soyturk"
# Please include the string: [perl #42320]
# in the subject line of all future correspondence about this issue.
# http://rt.perl.org/rt3/Ticket/Display.html?id=42320 >
The next program causes a memory leak for me.
.sub ma
# New Ticket Created by "Richard Hundt"
# Please include the string: [perl #42105]
# in the subject line of all future correspondence about this issue.
# http://rt.perl.org/rt3/Ticket/Display.html?id=42105 >
Hi,
The following PMC leaks memory at about 55Mb/100 calls to `call()'
#include
On Fri 15 Oct 2004 22:32, [EMAIL PROTECTED] (PerlDiscuss - Perl Newsgroups and mailing
lists) wrote:
> I need to embed Perl function in C program running as a daemon on Linux
> and Solaris. What it needs is to do pattern matching in Perl while it is
If pattern matching is your only goal, why not
At 8:32 PM + 10/15/04, [EMAIL PROTECTED] (PerlDiscuss - Perl
Newsgroups and mailing li wrote:
I need to embed Perl function in C program running as a daemon on Linux
and Solaris. What it needs is to do pattern matching in Perl while it is
difficult in C. However, frequently calling either of f
I need to embed Perl function in C program running as a daemon on Linux
and Solaris. What it needs is to do pattern matching in Perl while it is
difficult in C. However, frequently calling either of functions eval_pv or
perl_run would keep increasing the size of process. How come these
functions do
In message <[EMAIL PROTECTED]>
Nicholas Clark <[EMAIL PROTECTED]> wrote:
> Jarkko mailed this URL to p5p:
>
> http://developer.kde.org/~sewardj/
>
> It describes a free (GPL) memory leak checker for x86 Linux
>
> 1: This may be of use for parrot
Methamphetamine/Speed is probably unhealthy for parrots.
On 4/24/02 7:32 AM, "Nicholas Clark" <[EMAIL PROTECTED]> wrote:
> On Wed, Apr 24, 2002 at 12:26:57PM +0100, Nicholas Clark wrote:
>> Jarkko mailed this URL to p5p:
>>
>> http://developer.kde.org/~sewardj/
>
> I'd not twigged, but the
75 matches
Mail list logo
