memory increased rapidly when adding a break

Simon Marchi
Mon Nov 14 14:47:38 GMT 2022

> Thanks for your detailed explanation.
> Yes, it's `utility.h:560`, I added this break from vscode.
>> creating some internal data structures to represent it
> I wonder where would allocate so much memory, (at least 40GB),
> while the binary is 985MB with the whole debug info.
> Maybe many match results need too many memories?

It's hard to tell if it's a GDB bug, or it's working as expected, just
that GDB is inefficient.

If you end up expanding all CUs, it's not unrealistic.  I've just ran
gdb on itself, and did "maint expand symtabs" to force the expansion of
all symtabs.  htop shows 4.6 GB of virtual memory used.  So I can
imagine that for a project 10 times bigger, it can take 10 times more

>> Although I'm not sure this is what you see.
>> Is the project you build something open source that other people could
>> build and try?
> Yes, it's an open source project.
> It builds with Bazel and depends on Go, which may be a bit complicated.
> This is the doc for build & run.

I'm curious, so I built that, but then I'm not sure what to do, how to
reproduce your case.


More information about the Gdb mailing list