Re: debugging a memory leak

[tlaronde%polynum.com@localhost]

On Sun, May 22, 2016 at 06:22:29PM -0400, Dan LaBell wrote:
> 
> On May 21, 2016, at 4:10 AM, Manuel Bouyer wrote:
> 
> >On Sat, May 21, 2016 at 08:36:10AM +0200, tlaronde%polynum.com@localhost wrote:
> >>On Fri, May 20, 2016 at 11:43:11PM +0200, Manuel Bouyer wrote:
> >>>On Fri, May 20, 2016 at 02:20:39PM -0600, Swift Griggs wrote:
> >>>>On Fri, 20 May 2016, Manuel Bouyer wrote:
> >>>>>what tools do we have on NetBSD to find a memory leak in a
> >>>>>userland
> >>>>>program (actually OpenCPN - which is a large C++ program with
> >>>>>dynamic
> >>>>>libraries and uses dlopen()) ?
> >>>>
> >>
> >>I have used boehm-gc in the past on NetBSD. It is a garbage collector
> >>and allows to spot memory leaks too. It's in pkgsrc.
> >
> >thanks for the pointer. But if I understood it properly, the sources
> >needs to be modified ? I fear that in my case this is not an option:
> >opencpn is quite large and uses wxwidgets and glib, the memory may
> >be allocated from here too ...
> >
> I was considering replying about devel/boehm-gc  as well, but you would
> have to modify the build to use .a lib.  It seems to includes a lib that
> is just leak detection, so maybe just re-link.
> What about MALLOC_OPTIONS and /etc/malloc.conf ? And setting it to make
> utrace entries? man 3 jemalloc.

If there is a high-level include file, one has to put an 
"#include leak_detector.h" directive too, IIRC. 

This is probably "the" problem: a cdefs.h or whatever (or adapting
what is used to generate the program---autoconf or whatever to obtain
the same result) has to exist to ease the adaptation.
-- 
        Thierry Laronde <tlaronde +AT+ polynum +dot+ com>
                     http://www.kergis.com/
                     http://www.arts-po.fr/
Key fingerprint = 0FF7 E906 FBAF FE95 FD89  250D 52B1 AE95 6006 F40C