View Issue Details
|ID||Project||Category||View Status||Date Submitted||Last Update|
|0020264||Lazarus||Debugger||public||2011-09-15 19:38||2011-09-18 21:39|
|Reporter||Ludo Brands||Assigned To||Martin Friebe|
|Product Version||0.9.31 (SVN)||Product Build|
|Target Version||Fixed in Version||0.9.31 (SVN)|
|Summary||0020264: Setting breakpoints on a line that is not generating code can cause breaks in another unit.|
|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.
|Tags||No tags attached.|
|Fixed in Revision||32410|
The problem is in gdb, which is currently used by Lazarus.
Lazarus does tell gdb the exact line, but gdb does it's own choice.
It may be possible to check in advance if the desired breakpoint location exists, by asking for the entire line-info of the unit in question and then verify the desired line has debug info.
Such an approach can dramatically slow down staring an application. If the app has breakpoints across many units, then all of the units need to be verified.
If ever implemented, it will probably be optional.
A better approach, that should probably be implemented, is to verify the stack location at the time of the breakpoint hit, against the location originally desired. If not matching an appropriate message can be displayed.
When you do in gdb "info line source:line" for a line that is beyond the last one that created code, gdb returns "Line number x is out of range for "source" ".
Checking this before setting the breakpoint at source:line would be enough to avoid "out of unit" breakpoints which are the most annoying, especially when breaking in code without debug info. Or am I missing something?
Thanks for the update, I hadn't tried that => that can of course be used.
I have to test, how this works, with lines that are unavailable in the middle of a file.
In the middle of the file for "info line contest.pas:130" gdb returns "Line 130 of "contest.pas" is at address 0x401721 <main+129> but contains no code."
If you do then "info line *0x401721" you get "Line 143 of "contest.pas" starts at address 0x401721 <main+129> and ends at 0x401730 <main+144>." So you can deduct that between line 130 (the line initially requested) and line 143 there is no code. One needs to check that these lines are not comments (Edit: or just empty lines) to conclude that this is conditional code that is not compiled or code removed by the smart linking.
"info line *0x401720" (1 byte less) returns "Line 127 of "contest.pas" starts at address 0x401712 <main+114> and ends at 0x401721 <main+129>.". Indeed 128 to 142 are non-code lines in my test program.
line info test implemented in r 32405
please test and close if ok.
thanks for the help
updated to 32406 and can't get any breakpoints to work. Setting a breakpoint on a "blue point" turns the line green instead of red.
Also when the program finishes there is an exception runerror 131 in LNFODWRF_SEEK$INT64 with the message:
###(gdb unparsed remainder:s 0x0 out of bounds>)###
Are you using stabs or dwarf? Which version of fpc? Which version of GDB
please attach content of the "debug output" window
Edit: also 32 or 64 bit and OS
Used to be stabs but latest lazarus changed that to Automatic (dwarf with sets).
windows XP sp2 32 bit. fpc svn 2.7.1 18901. gdb 7.3
Lazarus svn 32404 works fine with dwarf2 and stabs.
Attached debug output for program run without breakpoints: run_no_breakpoints.log.
Debug output for program paused and set breakpoint: pause_set_breakpoint.log. There you'll see that the filename contains spaces that it needs to be double quoted. From gdb cli info line "C:\Documents and Settings\Ludo\Mes documents\Lazarus Projects\test\BufDataSet\contest.pas":144 works.
EDIT: added run_no_breakpoints_b.log. Run program from b:\, no space in filename. No exception and breakpoints can be set without problem. Out of unit test works.
EDIT: the program that raised the error is linked with heaptrc. Remove heaptrc and the exception is gone.
pause_set_breakpoint.log (33,860 bytes)
run_no_breakpoints.log (14,624 bytes)
run_no_breakpoints_b.log (11,298 bytes)
The exception can easily be reproduced with the following program:
Compile with -gw2 -gl -gh. The exception occurs only when there is a leak.
This is probably unrelated to the fix in 32405. I'll investigate further and probably raise another issue for this.
||please test again.|
out of unit breaks are solved.
I'll file a new issue for the dwarf/heaptrc crash.
|2011-09-15 19:38||Ludo Brands||New Issue|
|2011-09-15 19:38||Ludo Brands||Status||new => assigned|
|2011-09-15 19:38||Ludo Brands||Assigned To||=> Marc Weustink|
|2011-09-15 19:38||Ludo Brands||Widgetset||=> Win32/Win64|
|2011-09-17 22:39||Martin Friebe||Note Added: 0051967|
|2011-09-17 22:40||Martin Friebe||Assigned To||Marc Weustink => Martin Friebe|
|2011-09-18 12:16||Ludo Brands||Note Added: 0051974|
|2011-09-18 12:50||Martin Friebe||Note Added: 0051975|
|2011-09-18 14:26||Ludo Brands||Note Added: 0051978|
|2011-09-18 14:43||Ludo Brands||Note Edited: 0051978|
|2011-09-18 16:10||Martin Friebe||Fixed in Revision||=> 32405|
|2011-09-18 16:10||Martin Friebe||LazTarget||=> 0.99.0|
|2011-09-18 16:10||Martin Friebe||Status||assigned => resolved|
|2011-09-18 16:10||Martin Friebe||Fixed in Version||=> 0.9.31 (SVN)|
|2011-09-18 16:10||Martin Friebe||Resolution||open => fixed|
|2011-09-18 16:10||Martin Friebe||Note Added: 0051984|
|2011-09-18 16:10||Martin Friebe||Target Version||=> 0.99.0|
|2011-09-18 17:09||Ludo Brands||Status||resolved => assigned|
|2011-09-18 17:09||Ludo Brands||Resolution||fixed => reopened|
|2011-09-18 17:09||Ludo Brands||Note Added: 0051986|
|2011-09-18 18:30||Martin Friebe||Note Added: 0051988|
|2011-09-18 18:31||Martin Friebe||Note Edited: 0051988|
|2011-09-18 18:50||Martin Friebe||Note Edited: 0051988|
|2011-09-18 19:32||Ludo Brands||Note Added: 0051991|
|2011-09-18 19:32||Ludo Brands||File Added: pause_set_breakpoint.log|
|2011-09-18 19:33||Ludo Brands||File Added: run_no_breakpoints.log|
|2011-09-18 19:33||Ludo Brands||Note Edited: 0051991|
|2011-09-18 19:41||Ludo Brands||File Added: run_no_breakpoints_b.log|
|2011-09-18 19:44||Ludo Brands||Note Edited: 0051991|
|2011-09-18 19:50||Ludo Brands||Note Edited: 0051991|
|2011-09-18 20:43||Ludo Brands||Note Added: 0051995|
|2011-09-18 20:43||Martin Friebe||Fixed in Revision||32405 => 32410|
|2011-09-18 20:43||Martin Friebe||Status||assigned => resolved|
|2011-09-18 20:43||Martin Friebe||Resolution||reopened => fixed|
|2011-09-18 20:43||Martin Friebe||Note Added: 0051996|
|2011-09-18 21:39||Ludo Brands||Status||resolved => closed|
|2011-09-18 21:39||Ludo Brands||Note Added: 0051997|