In message Pine.LNX.4.21.0105142130540.150-100000@rusty.russwhit.com Russ Whitaker writes:

On Tue, 15 May 2001, Frank Heckenbach wrote: [..]

...

Another possibility: I recently read an article in the German c't magazin about glibc. If you're using it (most Linux systems do by now), you might be able to use its debugging facilities (look for mtrace() and $MALLOC_TRACE -- I hope there's something about it in the docs or on the net).

Try info glibc. There's a node called "Allocation Debugging" with 4 sub-nodes.

Don't know about earlier releases, but it is in glibc-2.2.2 release.

Thanks to Frank and Russ for those suggestions. MALLOC_TRACE, mtrace, and muntrace are also in glibc-2.1.3 (when I finally managed to get info libc to tell me anything).

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.

Now what I need to know is where is this being called from (unless anyone is able to say immediately 'ah yes ...'). I'd like to be able to get a call stack listing under program control. Any suggestions on how to do this, please?