Not able to set breakpoints while the process is running

Sysprogs forums Forums VisualGDB Not able to set breakpoints while the process is running

This topic contains 6 replies, has 2 voices, and was last updated by  support 12 hours, 29 minutes ago.

Viewing 7 posts - 1 through 7 (of 7 total)
  • Author
    Posts
  • #11224

    BitFlipper
    Participant

    Hi,

    I’m using VGDB on a few different project, including one that is very large and complex (300,000 files), and a simple one. The strange thing is that this works correctly on the complex project, but has problems on the simple one. So I know this should work.

    Basically, if I set breakpoints before starting a new instance, those breakpoints are hit properly. While stopped, I can set other breakpoints and they will also be hit once I continue. However, when the process is already running and I set a new breakpoint using F9, the GDB Timeout dialog pops up and will stay up unless I select Stop Debugging (I had it up for 10 minutes once).

    I followed the troubleshooting steps in the KB under “Break-in request hangs indefinitely”, but this made no difference.

    The strange thing is that if I select the GDB Session view mode as “Raw output from GDB”, the only thing it sends GDB when I try to add a breakpoint is:

    &”Quit\n”

    I also played with various setting related to the way it handles “Break All” etc but that also didn’t help.

    Thanks in advance for any help.

    #11227

    support
    Keymaster

    Hi,

    When you try to insert a breakpoint in a running program, VisualGDB sends a Ctrl-C signal to the gdb and it response gdb tries to halt your program. If anything on this path is broken, settings breakpoints in a running program won’t work.

    This could be caused by your program altering the handling of SIGINT or some system-wide settings. If it only happens with one project, we would recommend placing an infinite loop in main(), checking that ‘Break all’ still works, and then moving the infinite loop around to find the code that breaks the Ctrl-C handling.

    #11230

    BitFlipper
    Participant

    Hi,

    Thanks for the reply. So I added this at the start of main:

    While it is in the loop and currently running, I can set a breakpoint on the sleep and it will successfully place the breakpoint and then stop in the debugger.

    However, the strange thing is that if I do the same thing (while it is still looping at the same place), it fails to set a breakpoint at any other line in main. This is true for all other locations throughout the application as well. Note once again that if I set a breakpoint ahead of time at any other location in main, or anywhere else in the application, it correctly hits the breakpoints.

    So it is not that something stops Ctrl-C from working, since it works when I dynamically place a breakpoint inside the loop, but nowhere else. A bit strange.

    Maybe related: I noticed my path mapping is empty, however it doesn’t have any issues finding sources in all other cases, but I’m just mentioning it in case you think it could cause issues.

     

    • This reply was modified 1 week, 1 day ago by  BitFlipper.
    #11236

    support
    Keymaster

    Hi,

    The behavior you are describing would make 100% sense if the sleep loop was infinite (the optimizer would eliminate the rest of the code), but if it’s limited to 100 iterations, it should not happen.

    Please try pressing the ‘diagnose breakpoint problems’ button in the GDB Session window to automatically diagnose path mapping issues.

    #11263

    BitFlipper
    Participant

    The loop is not infinite, so the remaining code is not optimized out. In fact, if I place a breakpoint in the loop before I start debugging, when it hits the breakpoint in the loop I can then place breakpoints later in the main function (or anywhere else) and it will successfully hit it.

    To clarify: While the app is running and I try to place breakpoints, the following happens:

    • I get the “GDB Timeout” dialog, which doesn’t go away again even after 10 minutes.
    • If I click “Stop debugging” in the dialog, debugging obviously stops.
    • If I click “Retry break-in”, nothing seems to happen.
    • If I click “Cancel break-in”, sometimes the dialog goes away and the breakpoint is shown as sold, however it isn’t hit.
    • Other times when I click “Cancel break-in”, the “GDB Timeout” dialog pops up a second time, and when I click “Cancel break-in” again, I get a “Microsoft Visual Studio” error dialog stating the breakpoint could not be set. The breakpoint is then shown as not solid, and the tooltip shows the breakpoint is not valid.
    • If I click on “Diagnose breakpoint problems”, a “VisualGDB” dialog pops up and says no breakpoint problems were detected. This is while the breakpoint is shown as having problems.
    • Every time I try to set a new breakpoint, the raw GDB session output only shows a new line with “&”Quit\n”.

    It is important to note again that if breakpoints are set before debugging starts, or after another breakpoint was hit and it is currently stopped in the debugger, that any new breakpoints at that point will be set correctly without any issues.

    The problem seems more related to stopping the debugee successfully in order to set the new breakpoint (which is what I think VGDB needs to do), not resolving symbols. But that is just my guess.

    #11264

    BitFlipper
    Participant

    I figured out what the issue was. As mentioned before, there were no paths set in “Additional source path mappings”. After I added a mapping there, I’m able to set breakpoints while the app is running and it will hit them. So it is unclear why it can resolve them while the app is not running or while it is stopped in the debugger, but not while running in the debugger.

    Anyway it is working now so thanks for the help.

    EDIT: I spoke too soon. It just started behaving the same again so setting the path mapping wasn’t the solution it seems. I don’t know why it worked for a short while, then started behaving the way described earlier.

    Any ideas?

    • This reply was modified 3 days, 21 hours ago by  BitFlipper.
    #11280

    support
    Keymaster

    Hi,

    OK, this indeed looks like a break-in problem. Please try checking whether this behavior is consistent for all programs on the same Linux machine or if it is specific to one project (or one library used by the project).

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

You must be logged in to reply to this topic.