In message <200105161218.OAA21172(a)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.
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.
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@tcs01.demon.co.uk
Special Stage Rally results archive <URL:http://www.tcs01.demon.co.uk/>