Community
Participate
Working Groups
Created attachment 238758 [details] Breack points at invalid line numbers User can able to set break points at invalid line numbers. See the attachment. In the picture user can able to set break points at non-executable statements. All break points other than at line number 14, 15 and 21 are invalid here. Note: This is no possible in Java IDE of eclipse. OS: Ubuntu 13.10 Eclipse version: =================== Eclipse IDE for C/C++ Developers Version: Kepler Service Release 1 Build id: 20130919-0819 ================== How to reproduce ================== 1. Create C project using hello world template 2. Open any c file and double-click on break point ruler and try to set break points.
It is a bug in Eclipse CDT. Logged bug here https://bugs.eclipse.org/bugs/show_bug.cgi?id=425072
*** Bug 425072 has been marked as a duplicate of this bug. ***
Before setting a breakpoint the JDT actually looks at the code and figures out if a breakpoint can be set or not. This is also how it figures out if it should a line breakpoint or a method breakpoint or a class breakpoint. The CDT does not do that. CDT simply uses the filename and line to create the breakpoint. It sounds like a good enhancement to improve this, but I don't know how easy it or hard it would be. From what I have seen, dealing with C/C++ can prove more complicated than java for such things. I'll mark this as an enhancement if someone wants to contribute it.
Marc, wouldn't it be simpler to let GDB handle this? This was a bit discussed in bug 360280.
(In reply to Marc-Andre Laperle from comment #4) > Marc, wouldn't it be simpler to let GDB handle this? This was a bit > discussed in bug 360280. Yes and no. Users can set breakpoints without any debug session running; handling the invalid breakpoints directly in CDT would allow us to react as soon as the invalid bp is set, while relying on GDB would not. That does not mean it is worth doing in CDT, just that a CDT solution would be a super set of a GDB solution. Please also so more details in bug 425072 comment 2.