View Issue Details
|ID||Project||Category||View Status||Date Submitted||Last Update|
|0035405||Lazarus||Debugger||public||2019-04-17 22:49||2019-05-02 12:09|
|Reporter||nanobit||Assigned To||Martin Friebe|
|Fixed in Version||2.2|
|Summary||0035405: raise exception in debug mode|
|Description||in 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 Reproduce||procedure TForm1.Button1Click(Sender: TObject);|
caption := 'start';
raise Exception.Create('123'); // either initial-debugger-message or "Debugger Error"
on E: Exception do begin
caption := E.message;
|Tags||No tags attached.|
|Fixed in Revision||61102|
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
function TGDBMIDebuggerCommand.GetClassName(const AExpression: String;
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
||Please test if the workaround works for you|
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:
||Please test with rev 61102 (and workaround removed)|
Tested all dwarf versions and two gdb, is solved:
[Debugger Exception Notification] (symptom 1) is correct.
Symptom 2 [Debugger Error] disappeared.
|2019-04-17 22:49||nanobit||New Issue|
|2019-04-17 22:49||nanobit||Status||new => assigned|
|2019-04-17 22:49||nanobit||Assigned To||=> Martin Friebe|
|2019-04-18 00:20||Martin Friebe||Note Added: 0115620|
|2019-04-18 00:26||Martin Friebe||LazTarget||=> -|
|2019-04-18 00:26||Martin Friebe||Status||assigned => feedback|
|2019-04-18 00:26||Martin Friebe||Note Added: 0115621|
|2019-04-18 09:30||nanobit||Note Added: 0115640|
|2019-04-18 09:30||nanobit||Status||feedback => assigned|
|2019-05-02 10:18||Martin Friebe||Status||assigned => feedback|
|2019-05-02 10:18||Martin Friebe||Note Added: 0115949|
|2019-05-02 12:03||nanobit||Note Added: 0115954|
|2019-05-02 12:03||nanobit||Status||feedback => assigned|
|2019-05-02 12:09||Martin Friebe||Status||assigned => resolved|
|2019-05-02 12:09||Martin Friebe||Resolution||open => fixed|
|2019-05-02 12:09||Martin Friebe||Fixed in Version||=> 2.2|
|2019-05-02 12:09||Martin Friebe||Fixed in Revision||=> 61102|
|2019-05-02 12:09||Martin Friebe||LazTarget||- => 2.2|