I have a program that I intend to run for days or weeks at a
time, but it is being killed by the OS after a day or so, I think
because it is using up too much memory (growing over time). I
would like to be able to debug the memory leak and find out where
it is happening, so I can fix it.
What tool
On Mon Mar 02 01:04:52 2009, ml...@physik.uni-wuerzburg.de wrote:
> It seems that even the simplest programs leak memory:
>
> $ perl6 -e 'while 1 { }'
>
> Watching this in top (1) shows that it leaks about 1m per second on my
> machine (linux amd64).
>
It's interesting to note that while this le
# New Ticket Created by Moritz Lenz
# Please include the string: [perl #63594]
# in the subject line of all future correspondence about this issue.
# http://rt.perl.org/rt3/Ticket/Display.html?id=63594 >
It seems that even the simplest programs leak memory:
$ perl6 -e 'while 1 { }'
Watching
Christoph Otto via RT napsal(a):
Is this something we're still concerned about or can this ticket be closed?
If it isn't leak then it is a bug (in Parrot or in my PIR/PASM code). I
can invoke PASM compiler 10^5x (76MB RAM) but not 10^7x because I get
Parrot VM: PANIC: Out of mem!
C file src\gc\
On Thu Jun 14 16:25:24 2007, [EMAIL PROTECTED] wrote:
> On Thursday 14 June 2007 14:42:31 Jurosz Michal wrote:
>
> > Attached test use compreg P1, "PASM" and invokecc it 100,000 times.
> > On win32 (mingw32) it consumes 70MB of RAM with r18834 (107 MB of
> RAM
> > with r11704).
>
> With Linux at
On Thursday 14 June 2007 14:42:31 Jurosz Michal wrote:
> Attached test use compreg P1, "PASM" and invokecc it 100,000 times.
> On win32 (mingw32) it consumes 70MB of RAM with r18834 (107 MB of RAM
> with r11704).
With Linux at r19010, the memory use jumped up to 62 MB for me.
However, Valgrind s
# New Ticket Created by Jurosz Michal
# Please include the string: [perl #43218]
# in the subject line of all future correspondence about this issue.
# http://rt.perl.org/rt3/Ticket/Display.html?id=43218 >
Attached test use compreg P1, "PASM" and invokecc it 100,000 times.
On win32 (mingw32)
Jonathan Worthington wrote:
* Memory leak - string_to_cstring returns a malloced string, which isn't
freed everywhere
Thanks, applied -r8671
Note - yes, I know many of the strings are passed to
internal_excpection, but IIRC many of those will be becoming
real_exceptions in the future, so it
Hi,
From docs/ROADMAP
* Memory leak - string_to_cstring returns a malloced string, which isn't
freed everywhere
A quick grep through the src folder found a few cases like this. I may have
missed some, but this patch fixes those I spotted. Compiles, passes all
tests (apart from dynclasse
The short story: We have really too much leaks, everywhere:
Failed 33/57 test scripts, 42.11% okay. 291/903 subtests failed, 67.77%
okay.
(A test is considered failing above, when it has more then 3 leaks
(which are known to leak currently - the stdio handles))
The longer story:
Parrot has si
Brent Dax wrote:
> Leopold Toetsch:
> # 2) For bitmaps I would provide a bitlist.c with functions for setting
> # and testing bits. This bitlist would be based on list, so it
> # should be
> # fast enough and had no limits WRT unicode chars.
>
> Note that the "Bitmaps" used by rx are only bitmaps
Leopold Toetsch:
# 2) For bitmaps I would provide a bitlist.c with functions for setting
# and testing bits. This bitlist would be based on list, so it
# should be
# fast enough and had no limits WRT unicode chars.
Note that the "Bitmaps" used by rx are only bitmaps within US-ASCII, to
keep siz
Rx had some time ago (~0.0.6) a state structure rxinfo. AFAIK this was
tossed for speed reasons, state is kept in registers now.
This has several impacts:
- regexen are not reentrant anymore (global intstack)
- they don't/can't manage their allocated resources like bitmaps
1) I would propose, tha
Hope no one minds me essentially reposting this email. :)
> Am I correct in assuming that the stacks stuff leaks memory? Both stacks.c
> and rxstacks.c allocate memory via mem_allocate_aligned, but never free
> it, relying on the GC for it (code written before the GC existed).
There was a frame
At 4:43 AM -0500 3/26/02, Michel J Lambert wrote:
>Am I correct in assuming that the stacks stuff leaks memory? Both stacks.c
>and rxstacks.c allocate memory via mem_allocate_aligned, but never free
>it, relying on the GC for it (code written before the GC existed).
>
>Should these stacks be chang
Hey,
After going through and hopefully learning the GC system yesterday, today
I went through looking for problems in the code that uses it (or doesn't
use it, as the case may be). Below are what I believe to be potential
problems in Parrot's memory use. I may very well be mistaken on many of
the
16 matches
Mail list logo
