GDB memory usage with compressed debug info

[Matt Rice]

On Mon, Mar 22, 2021 at 6:16 PM Christian Biesinger via Gdb <
gdb@sourceware.org> wrote:

> On Thu, Mar 18, 2021 at 7:38 PM Mike Gulick via Gdb <gdb@sourceware.org>
> wrote:
> >
> > On 3/16/21 2:40 PM, Mike Gulick wrote:
> > > Hi,
> > >
> > > I'm observing that GDB memory usage is much higher when I have debug
> > > info compressed with 'objcopy --compress-debug-sections'.  In a large
> > > C++ application, I see the instance with uncompressed debug info use
> > > 46GB VIRTUAL memory and 11GB RSS, and the instance with compressed
> debug
> > > info is using 46GB VIRTUAL memory and 42GB RSS.  In case it matters,
> the
> > > debug info is separated from the original binary into its own file.
> > >
> > > It seems like GDB must load the full uncompressed debug info into
> memory
> > > when the underlying files are compressed?
> > >
> > > I'm currently using GDB 9.2.  I checked the 10.1 NEWS and didn't see
> > > anything that looked like it would have changed this result, but I'm
> > > happy to give it a try if you think it might help.
> > >
> > > Is there any chance this could be improved with a patch to GDB, or is
> > > this just the nature of compressed debug data?
> > >
> > > Also, FYI, the NEWS link for the GDB 10.1 release on the GDB home page
> > > points to the NEWS file for the 9.1 release.
> > >
> > > Thanks!
> > >
> > > -Mike
> >
> > I should add that this high memory usage only occurs when there is a
> > FILE:LINENUM breakpoint set (or pending).  I can run the application
> > being debugged, observe that GDB's memory usage is around 11 or 12 GB,
> > then run 'b foobar.cpp:123', and the GDB memory usage will climb up to
> > 42 GB.  Interesting that symbolic breakpoints don't trigger this high
> > memory usage, but line-based breakpoints do.  Does this seem expected?
>
> I'm guessing that this is due to parsing full debug info ("expanding
> psymtabs") which is not necessary for symbolic breakpoints, which can
> rely on minsyms or maybe psymtabs. Have you tried using a heap
> profiler to see where the memory usage comes from?
>

It could possibly narrow it down if the behavior of FILE:label breakpoints
differ, though I'm not sure what to expect exactly.