From: ahoward <ahoward@...>
Date: 2002-10-22T23:28:56+09:00
Subject: Re: rb_gc_register_address problem

On Tue, 22 Oct 2002, Paul Brannan wrote:

> > gcc has built in memory leak debugging - but it only works with c.  a
> > good reason not to use c++ imo. ;-)
>
> Where can I read more about this facility?

i told a little lie, it works with glibc, whcih on our systems is pretty much
synonymous with gcc (eg our linux systems).  you can read about it in

http://www.gnu.org/manual/glibc-2.2.3/html_mono/libc.html#SEC37

it's **really** usefull, and worth finding a machine with glibc on, at least
to debug with.

> > i actually have a modification, somewhere, which works with c++, want
> > it?
>
> What does the modification involve?

you'll see in the docs above, that turning tracing on outputs a file which a
perl postprocessor then handles.  it consists of lines like

i malloc'd 10 bytes to ptr 0x377
i free'd 0x377

etc..

the postprocessor scans this files and makes sure mallocs and frees are
balanced.  it also uses some backtracing functions to note *where* the leaks
occur.  the problem with c++ is that the leaks will always appear to occur
from the method 'new' (or whatever the internal name is).  note that this is
only because new and delete are implemented in terms of malloc and free in
glibc - maybe this is normal - i don't really know.  anyhow, i added some
checking that works using this logic

  if im called from new
    trace who called me
  else
    normal

in other words, when called from new i output information from further up the
call stack, so you can see where your new is leaking...

this modification requires rebuilding glibc!  however, the file affected is
the mtrace.c file, which is only ever used for memory debugging, so i assure
you nothing would break!  anyhow, it's been six months since i looked at that,
but if you want i'll scan my notes and send you a tar ball of what i did.
when time allows i will contrib this to gcc - but time has not yet allowed!

-a

-- 

 ====================================
 | Ara Howard
 | NOAA Forecast Systems Laboratory
 | Information and Technology Services
 | Data Systems Group
 | R/FST 325 Broadway
 | Boulder, CO 80305-3328
 | Email: ahoward@fsl.noaa.gov
 | Phone:  303-497-7238
 | Fax:    303-497-7259
 ====================================