Not able to set breakpoints while the process is running

[BitFlipper]

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.

[support]

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.

[BitFlipper]

Hi,

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

    for (int i = 0; i < 100; i++)
    {
        sleep(1);
    };

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 6 years, 11 months ago by BitFlipper.

[support]

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.

[BitFlipper]

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.

[BitFlipper]

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 6 years, 11 months ago by BitFlipper.

[support]

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

[BitFlipper]

OK I will try to gather more info (although I have just this one setup now so not sure when I can try other setups). Here are some other datapoints:

It seems to happen randomly, with roughly 90% of the time not being able to set a breakpoint while the debugee is running. The other 10% of the time it successfully sets the breakpoint while the debugee is running. It also doesn’t seem to matter where the breakpoint is placed, e.g., one moment it will work fine in a specific location, then press F5 and suddenly it will no longer be able to set a breakpoint again at the exact same location where it worked before during the same debug session.

When it works I can see the breakpoint activity in the GDB Session raw output window. When it doesn’t work, there is no activity in the GDB Session raw output window other than the single new “&”Quit\n” line.

Also, when it doesn’t work (i.e. 90% of the time), I need to kill the debug session and place breakpoints ahead of time before starting a new debug session again. This is annoying since I often need to place breakpoints after the fact (e.g. code that has already executed 1000’s of times), or alternatively rely on conditional breakpoints which has a big impact on performance.

Probably related: 90% of the time when doing “Break All”, it also fails with the single “&”Quit\n” line in the GDB Session raw output window. At that point I need to kill the debug session and start a new one.

If it helps, I’m running the debugee on Ubuntu 16.04 x64, debugging a Qt application. VS 2015 Pro Update 3, VGDB 5.2R9 (build 1452).

• This reply was modified 6 years, 11 months ago by BitFlipper.

[support]

Hi,

This could have something to do with the signal handling on the Linux side (incompatible combinations of gdb/kernel/libc). Please try checking if you can force the application to stop via “killall -s INT <application name>”. If yes, you can configure VisualGDB to use this command instead of the regular break-in mechanism via the Custom Debug Steps page (requires Custom edition).

[BitFlipper]

Yes this successfully works around the issue! After setting the custom break command in Custom Debug Steps, setting/clearing breakpoints and doing Break All are very reliable now.

Thanks for you help with this!

[Author]

Posts