David James wrote:
In message 200105161218.OAA21172@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.
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