Re: Large memory usage by gdb

[Philippe Waroquiers <philippe.waroquiers@skynet.be>]

On Fri, 2017-08-04 at 16:14 -0500, Alex Lindsay wrote:
> So I wanted to share what I've been doing to make sure that I'm not
> wasting my time (or the list's). 
For sure, fixing leaks is not wasted time.

> Since this is my first deep dive into valgrind, I started "simple".
> I've been running more or less:
> valgrind --xtree-leak=yes gdb --args ./hello


If you are only interested in leaks (definite and/or possible leaks)
and you do not have zillions of different leaks, then using
the classical text output for leak search might be easier.

If you use kcachegrind to visualise xtree leak reports,
you might have to tune the way the graph is shown by using
menus in the graph such as:
   right click -> Graph -> Caller Depth  -> ...
                        -> Callee Depth  -> ...
                        -> Min Node Cost -> ...



Once the leaks are solved, then to visualise the increase
of memory caused by a run in gdb, you might do (from a shell) :
   vgdb leak_check xtleak kinds all any
In kcachegrind, you can then analyse various 'events'
(typically for your case, you might look first at
   'increase Reachable Bytes'

Alternatively, to see memory increase in a textual output,
you might do:
   vgdb leak_check full kinds all increased
(if output too large, you can add
   limited 100
after increased
to output only the 100 (or whatever nr)  'biggest increase'.

Philippe