Re: GDB memory usage with compressed debug info

[Christian Biesinger via Gdb <gdb@sourceware.org>]

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?

Christian