Memory use problem
david at tcs01.demon.co.uk
Tue May 29 23:36:00 CEST 2001
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
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
Any further thoughts?
mailto:david at tcs01.demon.co.uk
Special Stage Rally results archive <URL:http://www.tcs01.demon.co.uk/>
More information about the Gpc