Sysprogs forums › Forums › VisualGDB › debug session crashes
Tagged: debug crash
- This topic has 3 replies, 2 voices, and was last updated 2 years ago by support.
-
AuthorPosts
-
October 17, 2022 at 00:10 #33320kridParticipant
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.October 17, 2022 at 09:46 #33323supportKeymasterHi,
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.
October 27, 2022 at 00:57 #33344kridParticipantHi,
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
October 28, 2022 at 09:54 #33349supportKeymasterHi,
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).
-
AuthorPosts
- You must be logged in to reply to this topic.