Memory use problem
frank at g-n-u.de
Wed May 30 04:03:44 CEST 2001
David James wrote:
> In message <200105161218.OAA21172 at goedel.fjf.gnu.de>
> Frank Heckenbach writes:
> > Oh yeah ... there were some places left in the RTS that did
> > allocation around the normal route, via GPC_GetMem. I've changed
> > them now (and removed GPC_GetMem and related routines), so such
> > leaks should now be reported via HeapMon as well.
> > I've also found and fixed a few leaks in this area. Maybe they are
> > what you're observing, though I'm not sure (the $a0 surprises me,
> > unless you're using a lot of typed files of a type of size $a0).
> > So, when my next patch is uploaded, you might want to try again with
> > HeapMon.
> Thanks. I've tried my test again using version 20010516.
> The heapmon report at the end of the program shows 4 undisposed
> pointers (which I would expect, they are 4 pointers into shared
> memory regions which I new at the start of the program and do
> not dispose of). The report from mtrace looks a lot better, but
> I still see some unfreed memory.
> These are from calls at lines 116 and 214 of rts/heap.pas.
> Sizes 0xd, 0x21, 0x5c, and the majority for 0xc08.
Those called from line 116 (which should all be $c08 on 32 bit
machines) are the internal structures used to keep track of the
pointers (i.e., if you don't use HeapMon and don't call `Mark'
anywhere in your code, they should disappear). I see that something
can be optimized to keep their number smaller, and I'll do this now,
but since you probably don't need HeapMon except for debugging, that
shouldn't be too important to you, I suppose.
About the other ones: The RTS uses a few of them to store internal
values. These intentionally don't show up in HeapMon, and their
number should be fixed (i.e., not growing when the program runs
longer). Besides them and the ones you allocated, there should be no
pointers allocated from line 214 (which is the main entry point for
In particular, without HeapMon the program should not lose more and
more memory now, I hope (and soon also with HeapMon).
Frank Heckenbach, frank at g-n-u.de, http://fjf.gnu.de/
GPC To-Do list, latest features, fixed bugs:
More information about the Gpc