Memory use problem

Frank Heckenbach frank at
Wed May 30 04:03:44 CEST 2001

David James wrote:

> In message <200105161218.OAA21172 at>
>    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.
> Frank, 
> 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
allocation) left.

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,
GPC To-Do list, latest features, fixed bugs:

More information about the Gpc mailing list