Fail to start GDB Session

Sysprogs forums Forums VisualGDB Fail to start GDB Session

Viewing 4 posts - 1 through 4 (of 4 total)
  • Author
    Posts
  • #25524
    Eric Kim
    Participant

    Hi, support.

    Before purchasing VisualGDB, I try to build a debugging environment by setting VisualGDB trial version with Debug_settings.PNG of attached file.

    When I run “Start Debugging with GDB”, Debugging ends with Error like GDB_Session.PNG and Failed_to_start_GDB_session.PNG of attached file.

    Did I miss anything?

    Attachments:
    You must be logged in to view attached files.
    #25545
    support
    Keymaster

    Hi,

    Looks like you forgot to specify the “–interpreter mi” argument in the gdb command line. This argument is required in order to enable the “machine interface” – a special mode where gdb produces machine-readable replies to commands instead of the regular text replies.

    VisualGDB would normally handle this automatically for the regular debug configurations, however using the fully custom mode shown on the screenshot requires specifying it manually.

    #25550
    Eric Kim
    Participant

    Hi,

    When I run “Start Debugging with GDB” with the argument you mentioned, Debugging ends with Error like Debugging_exited_unexpectedly.png and Text_in_Debugging_exited_unexpectedly.txt of attached file.

    Is there Anything else I missed?

    Attachments:
    You must be logged in to view attached files.
    #25555
    support
    Keymaster

    Hi,

    This one unfortunately looks like a bug in gdb itself:

    -var-create --frame 0 --thread 1 - * "Status"
    ^done,name="var23",numchild="1",value="{...}",type="CReturnCode",thread-id="1",has_more="0"
    -var-list-children --simple-values "var23\.public" 0 5
    bash: line 1: 25479 Segmentation fault (core dumped) /work/apm/crosstools/apm-aarch64/8.0.10-le/bin/aarch64-apm-linux-gnu-gdb -interpreter=mi --args uxx n=2

    The easiest way to resolve this would be to try building a newer gdb from source code (it’s usually much easier than building the entire toolchain and just involves running ./configure –target=<…> and making sure you have libexpat available). Another option would be to try specifying another debug information format in build settings (e.g. DWARF-2 or DWARF-4) or simply avoiding the evaluation of the variable that triggers the crash.

Viewing 4 posts - 1 through 4 (of 4 total)
  • You must be logged in to reply to this topic.