On Mon, Nov 14, 2022 at 10:47 PM Simon Marchi <simark@simark.ca> 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.