debug session crashes

[krid]

Hello,

while debugging my application the debug session rather often crashes. (see attached screenshot)

The last lines from the given error log are:

~"Reading in symbols for ../../../Statusanzeige/StatusanzeigeService.cpp...\n"
~"../../gdb/gdb/utils.c:671: internal-error: virtual memory exhausted: can't allocate 4064 bytes.\nA problem internal to GDB has been detected,\nfurther debugging may prove unreliable."
../../gdb/gdb/utils.c:671: internal-error: virtual memory exhausted: can't allocate 4064 bytes.
A problem internal to GDB has been detected,
further debugging may prove unreliable.
~"\nQuit this debugging session? "
~"(y or n) [answered Y; input not from terminal]\n"
&"\nThis is a bug, please report it."
&" For instructions, see:\n"
&"<https://www.gnu.org/software/gdb/bugs/>.\n\n"
~"../../gdb/gdb/utils.c:671: internal-error: virtual memory exhausted: can't allocate 4064 bytes.\nA problem internal to GDB has been detected,\nfurther debugging may prove unreliable."
../../gdb/gdb/utils.c:671: internal-error: virtual memory exhausted: can't allocate 4064 bytes.
A problem internal to GDB has been detected,
further debugging may prove unreliable.
~"\nCreate a core file of GDB? "
~"(y or n) [answered Y; input not from terminal]\n"
0-exec-interrupt

What can I do to prevent that error?

 

Thanks in advance

best regards

Dirk

Attachments:

You must be logged in to view attached files.

[support]

Hi,

This looks like a bug in the gdb executable, that is typically triggered by some constructs in the debug symbols. You can try working around it by:

• Using a different gdb executable from an older or newer toolchain.
• Explicitly selecting another DWARF version in gcc settings (e.g. -gdwarf-4).
• Stripping the debug information from the object files you are not intending to debug.

[krid]

Hi,

thanks for answering.

I selected dwarf 4 with no effort. Stripping debug information is no option because debugging is what I intend to do. So I switched to arm toolchain 12.2.MPACBTI-Bet1 which seems to avoid the total crash of the debug session. Although I still have slow target communication on hitting breakpoints. It takes long time to e.g. read variables and call stack. (I did not mention this before because this is a minor problem in comparison to a crash.)

best regards

[support]

Hi,

You can also try using DWARF 5. It is considerably different from DWARF4 and might work around the issue. Another thing to try would be using GDB indexes.

You can troubleshoot the slow gdb response by running the “set debug remote 1” command and checking whether the delay comes from the target answering GDB requests (e.g. OpenOCD) or gdb itself (i.e. happens between a reply and the next request).

[Author]

Posts