View Issue Details

IDProjectCategoryView StatusLast Update
0020264LazarusDebuggerpublic2011-09-18 21:39
ReporterLudo BrandsAssigned ToMartin Friebe 
PrioritynormalSeverityminorReproducibilityalways
Status closedResolutionfixed 
Product Version0.9.31 (SVN)Product Build 
Target VersionFixed in Version0.9.31 (SVN) 
Summary0020264: Setting breakpoints on a line that is not generating code can cause breaks in another unit.
DescriptionWhen 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.
TagsNo tags attached.
Fixed in Revision32410
LazTarget0.99.0
WidgetsetWin32/Win64
Attached Files

Activities

Martin Friebe

2011-09-17 22:39

manager   ~0051967

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.

Ludo Brands

2011-09-18 12:16

developer   ~0051974

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?

Martin Friebe

2011-09-18 12:50

manager   ~0051975

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.

Ludo Brands

2011-09-18 14:26

developer   ~0051978

Last edited: 2011-09-18 14:43

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.

Martin Friebe

2011-09-18 16:10

manager   ~0051984

line info test implemented in r 32405

please test and close if ok.

thanks for the help

Ludo Brands

2011-09-18 17:09

developer   ~0051986

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

Martin Friebe

2011-09-18 18:30

manager   ~0051988

Last edited: 2011-09-18 18:50

Are you using stabs or dwarf? Which version of fpc? Which version of GDB

please see:
http://wiki.lazarus.freepascal.org/GDB_Debugger_Tips#Create_a_new_Report

please attach content of the "debug output" window

Edit: also 32 or 64 bit and OS

Ludo Brands

2011-09-18 19:32

developer   ~0051991

Last edited: 2011-09-18 19:50

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.

2011-09-18 19:32

 

pause_set_breakpoint.log (33,860 bytes)

2011-09-18 19:33

 

run_no_breakpoints.log (14,624 bytes)

2011-09-18 19:41

 

run_no_breakpoints_b.log (11,298 bytes)

Ludo Brands

2011-09-18 20:43

developer   ~0051995

The exception can easily be reproduced with the following program:
program Project1;

var p:pointer;
begin
  getmem(p,5);
end.

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.

Martin Friebe

2011-09-18 20:43

manager   ~0051996

please test again.

Ludo Brands

2011-09-18 21:39

developer   ~0051997

out of unit breaks are solved.

I'll file a new issue for the dwarf/heaptrc crash.

Issue History

Date Modified Username Field Change
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