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
> >
> > > Initial conversation and relatively golfed down code:
> > > https://irclog.perlgeek.de/moarvm/2017-08-05#i_14973432
> > > https://gist.github.com/MasterDuke17/685b627a6a2749483dc5ec09c6a777a4
> > >
> > > dogbert11++ reproducing the issue
> >
mentation, 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 dynamic allocation) C
> library in an easier/more-comprehensive way than I could otherwise --
> though this
t 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 no dy
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
<da...@empireofgames.com> 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 no dynamic allocation
ke17/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)
> >
> > Mor
a6a2749483dc5ec09c6a777a4
>
> 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
>
>
e17/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 affects anybody else, but jd
h 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 my measuring and
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
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
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
# 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
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
ation of a trouble ticket regarding:
> "[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:
>
>
# 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
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;
}
-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
Gabor
Fortunately, it's not as bad as you think. Compare these two invocations:
time
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
On Sat, Jan 10, 2015 at 10:25 PM, t...@wakelift.de 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'm
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
Gabor
Fortunately, it's not as bad as you think. Compare these two
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
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 into a while
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
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
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
continually.
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,
once
# New Ticket Created by Paweł Pabian
# Please include the string: [perl #77644]
# in the subject line of all future correspondence about this issue.
# URL: 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
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] moritz_ eval '' while 1; also leaks
[11:59] moritz_ so I think it's eval() that
On Thu, Sep 2, 2010 at 10:35 AM, Patrick R. Michaud pmich...@pobox.com 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]
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 PMC
# New Ticket Created by Carlin Bingham
# Please include the string: [perl #70183]
# in the subject line of all future correspondence about this issue.
# URL: http://rt.perl.org/rt3/Ticket/Display.html?id=70183
This did not occur in 657d55cce1f1ded33fd1f731344bd31b33099cb8 but is
present in
# New Ticket Created by Will Coleda
# Please include the string: [perl #60540]
# in the subject line of all future correspondence about this issue.
# URL: 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
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 class_init() {
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 (previously
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.
# URL: 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
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 loop
.end
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 think
# 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.
# URL: http://rt.perl.org/rt3/Ticket/Display.html?id=47704
There is a memory leak with the STRING's. Next C code consumes more
/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;i2000;i++) {
string_from_literal(INTERP, nothing);
}
Hi,
Unless I'm mistaken, string_from_literal() is an allocation function
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;i2000;i++) {
string_from_literal(INTERP, nothing);
}
Unless I'm mistaken, string_from_literal
I think that the leak is at CParrot_PCCINVOKE.
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;i1000;i++) {
# 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.
# URL: http://rt.perl.org/rt3/Ticket/Display.html?id=47572
If you have defined an .HLL in your program, any pmc leaks. I could
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
[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?
I
segfaulting:
(gdb) p key
$1 = (PMC *) 0x1886030
(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 leak too
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
current_cont-to_ctx
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 caller context is accessible through
current_cont
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 right.
/io.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.
# URL: http://rt.perl.org/rt3/Ticket/Display.html?id=45991
In src/objects.c:Parrot_add_attribute() there is the todo item:
/* XXX leak! */
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 PMC somewhere
gets
garbage
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 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 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.
# URL: http://rt.perl.org/rt3/Ticket/Display.html?id=42790
Next program makes a slurpy tailcall, and it causes a memory leak
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
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
loop:
$S0 = foo
$P0 = new .String
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, no memory leak with:
.sub main :main
loop
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 collection
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
.end
That's an endless loop. How does one measure, if it's
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:
$P0 = new .String
goto loop
.end
That's
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 one measure, if it's leaking
.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
# 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.
# URL: http://rt.perl.org/rt3/Ticket/Display.html?id=42320
The next program causes a memory leak for me.
.sub main :main
loop
# New Ticket Created by Richard Hundt
# Please include the string: [perl #42105]
# in the subject line of all future correspondence about this issue.
# URL: http://rt.perl.org/rt3/Ticket/Display.html?id=42105
Hi,
The following PMC leaks memory at about 55Mb/100 calls to `call()'
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
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
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
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 author
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 hackers
Which is why I mentioned it a week
75 matches
Mail list logo
