Re: memory increased rapidly when adding a break

DeJiang Zhu via Gdb <[email protected]>
Newsgroups gmane.comp.gdb.devel
Message-ID <CAEZxTmkYpMW3Df5LYWGEZioBzO+M9Me+=c+U0qpGSGq_=UfAzQ@mail.gmail.com>
On Mon, Nov 14, 2022 at 10:47 PM Simon Marchi <[email protected]> wrote:

> > Thanks for your detailed explanation.
> > Yes, it's `utility.h:560`, I added this break from vscode.
>
> 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.
>
> I'm curious, so I built that, but then I'm not sure what to do, how to
> reproduce your case.
>

Thanks! I tried again, it really ended, after 13 minutes.

Also, as `top` shows, it takes `30+GB` memory.
```
   PID USER      PR  NI    VIRT    RES    SHR S  %CPU %MEM     TIME+ COMMAND
 16357 zhudeji+  20   0   31.9g  30.5g   7.2g S   0.0 49.0  13:34.93 gdb
```

Here are the steps, after build envoy
```
$ gdb --args ./envoy
Reading symbols from ./envoy...
(gdb) b utility.h:560
Breakpoint 1 at 0x361130b: utility.h:560. (2 locations)
```

Sorry, I can not reproduce `40+GB` memory again.
I tried with vscode again, it also ended, with `30+GB` memory.
Maybe I got a mistake, or something other changed.

I just `kill -9` before it eats huge memory in the next debugging,
after I hit `40+GB` once, since it makes the whole system nearly stuck.
I'm so sorry for the wrong info.

Thanks a lot again.
Also, hope gdb could optimize it if it could be there.
lmpx.com only provides a reader for public news (NNTP) servers. It is not affiliated with the servers or forums shown here and is not responsible for the content of articles, which is written by their respective authors.