[Bug gdb/28219] arm-none-eabi-gdb, .../gdb/utils.c:671: "internal-error: virtual memory exhausted: can't allocate 4064 bytes"

["luis.machado at arm dot com" <sourceware-bugzilla@sourceware.org>]

https://sourceware.org/bugzilla/show_bug.cgi?id=28219

--- Comment #13 from Luis Machado <luis.machado at arm dot com> ---
It is not directly tied to the size of the binary or the size of the debug
information, but older versions of the tools used to produce what was said to
be pathological entries. For instance:

DW_MACRO_import - offset : 0x0

It was investigated a bit more in here:
https://sourceware.org/bugzilla/show_bug.cgi?id=27754

Some hinted at LTO issues, but it doesn't look like it is LTO-specific. Newer
versions of the tools started to behave better, as some users reported. The
fact is that this isn't an issue specific to 32-bit Arm gdb, though the fact
32-bit Arm is widely used/debugged means people may see it more often in that
setup. It is gdb finding some odd input that makes it load more things than it
should. Or load the same data multiple times.

The Windows tools made available by Arm suffer from a couple of issues. First
is the gdb side-effect of bad input. The second is that those Windows tools are
32-bit (which restricts memory use to 4GB). So the first issue may force you to
run into the second one. Not good.

Some suggested we skip the pathological entries in gdb. And there was also a
suggestion to not expand a macro more than once. I did a little experiment with
disabling macro expansion (even in the presence of macro information in the
debug info) and saw a significant memory use drop. It also loads things much
quicker.

I think this might be an opportunity to teach gdb how to deal with these a
little better.

-- 
You are receiving this mail because:
You are on the CC list for the bug.