Why does Eclipse CDT ignore breakpoints?

Question

My problem is that I set some breakpoints in my code and some of them aren\'t working. In some places it complains about \"Unresolved Breakpoint\".

Does anyone have

Answer 1

I have found that using F8 (resume) doesn't stop at my breakpoints. But, if I have Stop On Startup : main set then then step over my code (F5/F6) then my breakpoints are hit. I don't have any special compiler options other than -g or -g3. Hope that help...

Answer 2

If other answers here didn't solve your problem, it is possible you are having the same problem I had (which was the result of having an outdated version of GDB). This is likely the case for anyone using GDB on Mac.

See my question and answer here:

GDB does not break on some lines of code when using multiple source files

Answer 3

Amazing that there are so many different answers to this question. There is still (2020) a problem in Eclipse 2019.12, CDT 9.10, RHEL 8.0, x86_64. In my case, I can fix it by adjusting the breakpoint properties, and changing it from 'regular' to 'hardware' (select the breakpoint window, then right-click on the breakpoint, Breakpoint properties, common, type).

Answer 4

Do you place a breakpoint in a template class/function? I've met the same problem: I can step through the code of templates but breakpoints do not work. I guess eclipse does not understand that it has to place breakpoints in all instantiations of that class:

template <typename T>
int doit(T a) {
 return a.do(); // <-- breakpoint here
}
...
A a;
cout << doit(a);

I think it will wait for doit(...) and never for doit(...). At lease gdb itself stops on the breakpoint if I set it to the function: 'doit'.

Answer 5

Could it be that you are trying to set breakpoints in a shared library that has not been loaded yet. That won't work until the library has loaded. Newer gdb allow to set deferred breakpoints, but that may not (yet) be supported by CDT. A workaround is to set a breakpoint in a place that is available from the beginning that will be reached when the shared library in question is already loaded. Then set the other breakpoint in the shared library. Now it should work. It's a bit more tedious, but usually works.

From the GDB documentation:

For a pending breakpoint whose address is not yet known, this field will contain 'PENDING'. Such breakpoint won't fire until a shared library that has the symbol or line referred by breakpoint is loaded.

Answer 6

IF you are using GDB as a debugger, make sure you are using both flags: -g and -ggdb

You can either edit the make file directly, FCFLAGS = -g -ggdb (some other flags you might have)

or go to Debug Configuration (It's in the menu that drops down when you click on the little arrow besides the bug icon.) Select the project you are debugging, and click on the debugger tab. Check you are using gdb, and add the flags here.