View Issue Details

IDProjectCategoryView StatusLast Update
0035405LazarusDebuggerpublic2019-05-02 14:09
ReporternanobitAssigned ToMartin Friebe 
PrioritynormalSeverityminorReproducibilityalways
Status resolvedResolutionfixed 
Platformwin32OSWindowsOS Version10
Product Version2.0.2Product Build 
Target VersionFixed in Version2.2 
Summary0035405: raise exception in debug mode
Descriptionin debug-mode, raise exception leads to debugger-error in Lazarus 2.0.2.
Probably (IIRC) the symptoms are new with this version, which would mean this is solvable. I have not tried trunk.

For the 4 pairs (gdb (default/v8.2) + fpDebug (yes/no)), with dwarf:
The symptoms are not constant, but at least symptom1 happens:
- symptom1 (mostly): initial debugger-message displays exception message unlike '123'
- symptom2 (more likely on 2nd button-click): "Debugger Error":
   "The GDB command: "-data-evaluate-expression ^^shortstring(^POINTER($eax)^+12)^^" did not return any result."
- (gdb + fpdebug) adds symptom3 (if "break" was clicked in initial debugger-message):
   After Lazarus close, heaptrc reports debugger memory-leaks (in fpdbgdwarf).
   (My Lazarus was built with -Ci -Cr -Co -Ct -O -gw3 -gl -gh -gt)
Steps To Reproduceprocedure TForm1.Button1Click(Sender: TObject);
begin
caption := 'start';
try
  raise Exception.Create('123'); // either initial-debugger-message or "Debugger Error"
except
  on E: Exception do begin
    caption := E.message;
  end;
end;
end;
TagsNo tags attached.
Fixed in Revision61102
LazTarget2.2
Widgetset
Attached Files

Activities

Martin Friebe

2019-04-18 02:20

manager   ~0115620

Symptoms 1 & 2 would be independent of the fpdebug part.

I can only reproduce them with gdb 8.2 (not tested all the other alternative versions, but default gdb for 32bit IDE worked) AND dwarf 3.
Also only tested with fpc 3.0.4 This may depend on the version of fpc.

Dwarf 2 works correct. (for me).


I have not checked with 2.0.0. But there were no changes to any related code. Also I have observed gdb (in various versions) to crash on dwarf 3 generated by fpc (especially in expressions that use pointer arithmetic with string types, such as getting the exception msg)


When using the +fpdebug version GDB normally does not get into contact with dwarf 3 for data. Except on exceptions (or watchpoints)


--
The leaks may currently go on a waitlist, as they depend on other work planed long term for fpdebug.

---------------
As for a workaround
components\lazdebuggergdbmi\gdbmidebugger.pp
line 11370

function TGDBMIDebuggerCommand.GetClassName(const AExpression: String;

comment out
    UseShortString := tfFlagHasTypeShortstring in TargetInfo^.TargetFlags;

So UseShortString will remain false.

Not sure if that causes other side-effects on any Win-version/Gdb/fpc/bitness combination.
So don't really want to change the default.

If the workaround works for you, then it depends how easy it is for the debugger to detect what dwarf type is in use....


---------------
I have not seen the exception msg itself being wrong. If you do get wrong messages, then look around at line 5684

Martin Friebe

2019-04-18 02:26

manager   ~0115621

Please test if the workaround works for you

nanobit

2019-04-18 11:30

reporter   ~0115640

Yes, this source change prevents the "Debugger Error", which was the biggest issue.
I tested ok with all dwarf versions and the four (gdb[+fpdebug]) combinations.

The exception message is wrong only in the [Debugger Exception Notification].
If I use inttostr(123) instead of '123', then the text may vary between clicks.
For example, "Project project1 raised exception class 'Exception' with message:
,��

Martin Friebe

2019-05-02 12:18

manager   ~0115949

Please test with rev 61102 (and workaround removed)

nanobit

2019-05-02 14:03

reporter   ~0115954

Tested all dwarf versions and two gdb, is solved:
[Debugger Exception Notification] (symptom 1) is correct.
Symptom 2 [Debugger Error] disappeared.

Issue History

Date Modified Username Field Change
2019-04-18 00:49 nanobit New Issue
2019-04-18 00:49 nanobit Status new => assigned
2019-04-18 00:49 nanobit Assigned To => Martin Friebe
2019-04-18 02:20 Martin Friebe Note Added: 0115620
2019-04-18 02:26 Martin Friebe LazTarget => -
2019-04-18 02:26 Martin Friebe Status assigned => feedback
2019-04-18 02:26 Martin Friebe Note Added: 0115621
2019-04-18 11:30 nanobit Note Added: 0115640
2019-04-18 11:30 nanobit Status feedback => assigned
2019-05-02 12:18 Martin Friebe Status assigned => feedback
2019-05-02 12:18 Martin Friebe Note Added: 0115949
2019-05-02 14:03 nanobit Note Added: 0115954
2019-05-02 14:03 nanobit Status feedback => assigned
2019-05-02 14:09 Martin Friebe Status assigned => resolved
2019-05-02 14:09 Martin Friebe Resolution open => fixed
2019-05-02 14:09 Martin Friebe Fixed in Version => 2.2
2019-05-02 14:09 Martin Friebe Fixed in Revision => 61102
2019-05-02 14:09 Martin Friebe LazTarget - => 2.2