David James wrote:
So ... I put a call to mtrace at the start of my message handling loop and a call to muntrace at the end of my message handling loop, in such a way that I turn the tracing on for exactly one pass though the loop. Then I ran the mtrace script on the resulting output ...
I get 4008 unfreed blocks (that number is not relevant, except as an indication that there's a lot of memory allocation going on), all of them have been called from line 121 of rts/heap.pas. They are for varying memory sizes (a quick glance shows 0x1, 0xd, 0x21, 0x1e, 0x5e and an overwhelming majority for 0xa0).
This is with the 20010512 GPC release. I think that source line is p:=GetMemPtr^(Size) in GPC_GetMem.
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