What is this? Why does it always take so long? (20+ seconds)

Sysprogs forums Forums VisualGDB What is this? Why does it always take so long? (20+ seconds)

This topic contains 12 replies, has 2 voices, and was last updated by  support 1 week, 6 days ago.

Viewing 13 posts - 1 through 13 (of 13 total)
  • Author
    Posts
  • #12566

    Ophidian14
    Participant

    #12567

    support
    Keymaster

    Hi,

    This could be caused by some toolchains-specific or connection-specific issues. We can help you troubleshoot this if you could let us know the email associated with your license so that we could verify your support status.

    #12572

    Ophidian14
    Participant

    I will send my email to support directly to verify my support status.  Note, when this display is on the screen, gdb on the backend is at 100% CPU and its memory usage is climbing rapidly.

    #12576

    support
    Keymaster

    Hi,

    Thanks for verifying your support status.

    It looks like the gdb executable is either hanging while VisualGDB is trying to execute initial commands, or the communication between VisualGDB and gdb is broken.

    Please try enabling the gdb logging via VisualGDB Project Properties -> Advanced GDB Settings, then reproduce the problem, cancel the session and view the gdb log.

    Do you see just one ‘-data-evaluate-expression’ command or multiple commands sent rapidly? If it is just one command, please try running gdb manually using the command line shown in the log and re-running the same commands. Does this trigger the gdb hang?

    #12589

    Ophidian14
    Participant

    Ran the logger and observed this:

    Ran the command by hand with gdb –interpreter mi.  Saw the same thing, 20+ second delay but subsequent commands returned immediately.

    In terms of what was going on during the delay.  In “top” I could see gdb going from virt 549MB / res 190MB, to, 2583MB virt / 2256MB res.  And during this time, strace -f on the gdb process just showed a long stream of brk() system calls (consistent with the memory growth, obviously) interspersed with a few calls to mmap().

    So I guess the question is, what would cause

    to balloon the size of the GDB process?  What is it trying to do, and what about my debug target is causing it to be so expensive?  How would I figure that out, would I need to debug gdb?

    Also is there a way to cache the results of these -data-evaluate-expression calls so that I can avoid this problem altogether?

    #12590

    Ophidian14
    Participant

    Debugged gdb and broke in a few times while it was in this loop.  Here are a few select stack frames.

     

    #12591

    Ophidian14
    Participant

    One other point of information.  Running gdb 7.12 from devtoolset-6 doesn’t seem to incur this delay.  That is, it can evaluate sizeof(void *) immediately.  I will try integrating this into my config.

    #12593

    Ophidian14
    Participant

    Just one followup, I eventually experienced the “evaluate sizeof” hang later on in my debugging session on one of my own types, so I don’t think gdb 7.12 is the solution necessarily.

    #12597

    support
    Keymaster

    Hi,

    This looks like a buggy gdb build or some incompatibility between gdb and the debug information format. Were you able to debug your programs on that machine successfully before? If yes, we would advise trying to revert to the gdb version that worked.

    Another option would be to check if the gdb hang is related to the debugged binary (e.g. does it hang with no debugged binary or with a simple “hello, world” program?). If yes, changing the debug information format (e.g. -gdwarf-2) might solve this. If the program consists of many large shared libraries, stripping the ones you don’t want to debug (using the ‘strip’ command) will reduce the amount of symbols loaded in gdb and could also improve performance.

    Yet another option would be to try running gdb on the Windows side instead (note to other readers: this requires the Custom edition). With VisualGDB 5.3 it’s as easy as selecting “allow changing build/debug command host” on the first page of VisualGDB Project Properties, adding an action to download the built binary on Windows and then changing “gdb executable” on the Debug Settings page to your Windows gdb.exe (it needs to match the Linux target type). VisualGDB will then figure out how to use gdbserver and update the startup commands automatically.

    #12600

    Ophidian14
    Participant

    I tried -gdwarf-2 and shrinking the binary as much as I could, didn’t make a difference.

    One thing I feel I have should have mentioned, but didn’t:  all this code was compiled with Clang i.e. LLVM.  When I compile with gcc, I haven’t been able to reproduce the problem.  The problem is, my larger code base does not compile with gcc due to errors, so I can’t really switch.

    It is probably just some incompatibility/bug between Clang and gdb.

    #12614

    support
    Keymaster

    Hi,

    This could be the case. We would advise trying lldb-mi instead of gdb (LLDB is the debugger from the clang/llvm suite) that might work with clang-generated code better. VisualGDB supports it, although it is generally less feature-complete and less stable than gdb.

    #12631

    Ophidian14
    Participant

    I tried lldb, setting a breakpoint in main(), running my program and hitting the breakpoint took almost 1 minute.  So that’s not going to work.  Thanks though.

    #12632

    support
    Keymaster

    Hi,

    Thanks for confirming this. The only other advice would be to ask in the clang/llvm mailing lists. This might be a known issue and someone from the clang community might be able to suggest a better workaround.

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

You must be logged in to reply to this topic.