Memory use problem

David James david at
Tue May 29 23:36:00 CEST 2001

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.


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.

Looking at the RTS source these lines are the calls to GetMemPtr^ 
in GPC_New and GPC_Mark.

I'm not sure how to get any further information for you ... I could
try running the program under a debugger, breakpointiung at these
routines and looking at the call stack, but that's going to take a
long while.

Any further thoughts?

David James
mailto:david at
Special Stage Rally results archive <URL:>

More information about the Gpc mailing list