debug session crashes

Sysprogs forums Forums VisualGDB debug session crashes

Tagged: 

This topic contains 3 replies, has 2 voices, and was last updated by  support 3 months ago.

Viewing 4 posts - 1 through 4 (of 4 total)
  • Author
    Posts
  • #33320

    krid
    Participant

    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.
    #33323

    support
    Keymaster

    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.
    #33344

    krid
    Participant

    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

    #33349

    support
    Keymaster

    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).

Viewing 4 posts - 1 through 4 (of 4 total)

You must be logged in to reply to this topic.