Setting breakpoints on a line that is not generating code can cause breaks in another unit.
Original Reporter info from Mantis: ludob
-
Reporter name: Ludo Brands
Original Reporter info from Mantis: ludob
- Reporter name: Ludo Brands
Description:
When a breakpoint is set on a line that is not generating code, the breakpoint will be set on the first code encountered thereafter. When there is no more code in the unit, the breakpoint will be set in the next unit, whatever that is. The problem occurs when putting breakpoints in conditional code. As long as the program isn't build, the "blue dots" indicating executable code aren't present and breakpoints can easily be set on code that won't be compiled. Because the debugger breaks at an unexpected place/unit and no red dot/line indicating a breakpoint is inserted, it can take a while before understanding why the debugger breaks and where the "wrong" breakpoint is.
I understand why the breakpoint has to be fuzzy since lines such as begin or end don't always generate code. Limiting this fuzzyness to the same unit and to x lines beyond would be helpful.
Mantis conversion info:
- Mantis ID: 20264
- Version: 0.9.31 (SVN)
- Fixed in version: 0.9.31 (SVN)
- Fixed in revision: 32410 (#d65d00c3)
- Monitored by: » etrusco (Flávio Etrusco)
- Target version: 0.99.0