public inbox for gdb@sourceware.org
 help / color / mirror / Atom feed
From: Simon Marchi <simark@simark.ca>
To: DeJiang Zhu <doujiang24@gmail.com>
Cc: gdb@sourceware.org
Subject: Re: memory increased rapidly when adding a break
Date: Mon, 14 Nov 2022 09:47:38 -0500	[thread overview]
Message-ID: <5a0a91a5-fc65-c9e9-89ea-035884b9c867@simark.ca> (raw)
In-Reply-To: <CAEZxTmn7u=9DNXg7zHr1c8L=3YZP84MRHK-67iCCgFnLOMSoEA@mail.gmail.com>

> 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
memory.

>>
>> 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.
> https://github.com/mosn/envoy-go-extension#envoy

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

Simon

  reply	other threads:[~2022-11-14 14:47 UTC|newest]

Thread overview: 5+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2022-11-13 10:01 DeJiang Zhu
2022-11-14  0:26 ` Simon Marchi
2022-11-14  3:58   ` DeJiang Zhu
2022-11-14 14:47     ` Simon Marchi [this message]
2022-11-15  1:34       ` DeJiang Zhu

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=5a0a91a5-fc65-c9e9-89ea-035884b9c867@simark.ca \
    --to=simark@simark.ca \
    --cc=doujiang24@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;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).