Memory use problem

David James david at
Wed May 16 00:38:00 CEST 2001

In message <Pine.LNX.4.21.0105142130540.150-100000 at>
   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?

David James
mailto:david at
Special Stage Rally results archive <URL:>

More information about the Gpc mailing list