Mirror of the gdb mailing list
 help / color / mirror / Atom feed
From: Philippe Waroquiers <philippe.waroquiers@skynet.be>
To: Alex Lindsay <alexlindsay239@gmail.com>
Cc: gdb@sourceware.org
Subject: Re: Large memory usage by gdb
Date: Tue, 01 Aug 2017 19:12:00 -0000	[thread overview]
Message-ID: <1501614717.1461.3.camel@skynet.be> (raw)
In-Reply-To: <832a7365-8905-a49e-b97d-2d8a3520c747@gmail.com>

On Mon, 2017-07-31 at 17:11 -0500, Alex Lindsay wrote:
> Philippe,
> 
> Is memcheck a better tool to use here compared to massif?
In valgrind 3.13, memcheck provides a quite detailed/precise
way to see delta memory increase/decrease.
Typically, you will give --xtree-memory=full argument,
and then e.g. use vgdb to launch a (delta) leak search
after each run.
You can then use kcachegrind to visualise the resulting
memory increase.

Massif is IMO less precise, but automatically produces
memory status at regular interval.

So, in summary, I would use valgrind 3.13 and memcheck
(with an additional benefit that if ever your use case
causes real memory leaks, memcheck will detect them).

Philippe

> 
> Alex
> 
> On 07/25/2017 03:28 PM, Philippe Waroquiers wrote:
> > Run gdb under Valgrind, and make some heap profiling dump at regular
> > interval, (e.g. after each run).
> >
> > With valgrind 3.12 or before, you can do a leak report to show
> > the delta (increase or decrease) compared to the previous leak search,
> > including the reachable blocks. So, you will be able to see what
> > increases the memory.
> >
> > If you compile the latest Valgrind (3.13), you can e.g. use memcheck
> > and produce heap profiling reports readable with kcachegrind.
> >
> > You will need a gdb compiled with debug or install the debug info
> > of gdb to have understandable stack traces.
> >
> > Philippe
> >
> > On Tue, 2017-07-25 at 15:20 -0500, Alex Lindsay wrote:
> >> My OS is Ubuntu 17.04. Using both gdb 7.12 and 8.0, I experience large
> >> memory usage when debugging my executable. As I add breakpoints and run
> >> the executable multiple times in a single session, memory usage grows
> >> continuously, regularly hitting 10s of GBs. I don't recall experiencing
> >> this issue with earlier Ubuntu versions (and also likely earlier
> >> versions of gdb). When I debug the same executable with `lldb`, memory
> >> usage is pretty much constant at around 2 GB. Does anyone have any
> >> suggestions?
> >>
> >> Alex
> >
> 



  reply	other threads:[~2017-08-01 19:12 UTC|newest]

Thread overview: 12+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2017-07-25 20:20 Alex Lindsay
2017-07-25 20:28 ` Philippe Waroquiers
2017-07-31 22:11   ` Alex Lindsay
2017-08-01 19:12     ` Philippe Waroquiers [this message]
     [not found]       ` <420b109c-1610-d687-ae9a-b172542fafca@gmail.com>
2017-08-04 21:43         ` Alex Lindsay
2017-08-07  9:16           ` Yao Qi
2017-08-07 19:53             ` Philippe Waroquiers
2017-08-07 21:04               ` Alex Lindsay
2017-08-07 21:34                 ` Simon Marchi
2017-08-07 18:19         ` Philippe Waroquiers
2017-07-26  7:28 ` Yao Qi
     [not found]   ` <4fc14853-b066-4fd7-f0c9-b98f442a9a95@gmail.com>
2017-07-26 15:55     ` Yao Qi

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=1501614717.1461.3.camel@skynet.be \
    --to=philippe.waroquiers@skynet.be \
    --cc=alexlindsay239@gmail.com \
    --cc=gdb@sourceware.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox