View Issue Details
|ID||Project||Category||View Status||Date Submitted||Last Update|
|0034502||Lazarus||Debugger||public||2018-11-03 14:34||2020-07-01 18:30|
|Reporter||nanobit||Assigned To||Martin Friebe|
|Product Version||2.1 (SVN)|
|Summary||0034502: Lazarus WIN32_SEH debugging with F8|
|Description||I tried newest FPC versions (3.2, trunk), made with dTEST_WIN32_SEH,|
and how apps react on an (invalid) operation which causes an OS-exception (AV, divByZero, floating point exception):
The debugger correctly shows error message for the OS-exception, but after the message the continuation differs by key command:
a) stepping further with F8 (or F7) is faulty:
Errors (new AVs, privilege problems, ...) arise in all following operations.
This appears regardless of the type of OS-exception.
b) pressing F9 (to reach next breakpoint if there is any), this works.
In summary, there is a big difference between F8 (failure) and F9 (success).
|Tags||No tags attached.|
|Fixed in Revision|
While the issue itself is valid, I can not reproduce the described effect.
procedure TForm1.FormCreate(Sender: TObject);
b, a: Integer;
Caption := '111';
a := 1;
b := b div (b-1-a); // div zero
Caption := '123';
Will show a sigfpe once. After that there is no further exception (signal or raise).
F8 does not (or only once). The program is at that point in some code without debug info (probably kernel). If there is no debug/line info, single stepping is not available (error from gdb "can not find function boundaries"). Assembler single step works.
I do not get as described in the issue "Errors (new AVs, privilege problems, ...)" when using F8.
Nevertheless the following issues exist:
1) Errors from gdb, are not "translated", they are not always meaningful (e.g. "can not find function boundaries")
This is a separate issue, and known
2) F8 should step to either finally or except.
This is not yet implemented.
As a workaround set a breakpoint in the next finally/except, and use F9
IMHO, the other errors I mentioned don't need to be investigated.
If F8 is implemented, then those errors will disappear.
Currently they can happen, in your example: first I press F8 on the div-by-zero line. After the message, the next F8 press goes into TControl.SetText(const Value: TCaption); and therein causes a SigSEGV at HostDockSite.UpdateDockCaption(nil).
Such errors appear to be only sideeffects of the first F8.
Tested with FpDebug: When I set a breakpoint on "jmpl *%ecx" in seh32.inc/CommonHandler(),
then F8 will land at breakpoint, and the next F8 will reach the except block as wanted.
The breakpoint does not work with gdb + system-exception ( F8 goes to line far before breakpoint (leads to later crash)),
but F8 works with gdb + other exceptions (rec.ExceptionCode = FPC_EXCEPTION_CODE),
which come from fpc_RaiseException() (in raise exception.create())
>> breakpoint on "jmpl *%ecx"
But that line has no debug info. (In normal installations).
All breakpoints must be calculated from some known starting point.
Which in this case is: TargetAddr (one of the params to CommonHandler), only CommonHandler has no debug info either.....
The info can probably be gotten by tracing it far enough, and intercepting at some known point.....
Of course that may very well rely on the assumption that fpc will not change certain internal structures.
Martin, have you changed something in this regard? In FpDebug:
my F8 workaround (programmatic breakpoint) for all debugger types: "except asm int 3; end; .... end;"
seems to be ignored now after raise exception.create().
Earlier this year (or end of last year) I did work on 64bitSEH. Not sure if that may affect you.
Is the breakpoint shown in full red (active)?
Or is it orange?
Or does it have 2 green bars (pause symbol on breakpoint)?
Maybe take this specific issue to the forum.
Fixing your workaround is not part of this issue here.
Sorry I was not precise. It ceased to work only after my update from Lazarus trunk today.
With FpDebug: After raised exception, the F8 jump does not halt in except block (contains programmatic breakpoint),
but did halt in all previous versions: F8 jumped to the line after the programmatic breakpoint (which has blue dot).
This worked for all exceptions (not only system exceptions) and without any debugger (IDE) breakpoints.
The programmatic breakpoint could also be a call to windows.debugBreak.
|2018-11-03 14:34||nanobit||New Issue|
|2018-11-03 14:34||nanobit||Status||new => assigned|
|2018-11-03 14:34||nanobit||Assigned To||=> Martin Friebe|
|2018-11-08 16:04||Martin Friebe||Note Added: 0111865|
|2018-11-08 16:05||Martin Friebe||Note Edited: 0111865||View Revisions|
|2018-11-09 11:59||nanobit||Note Added: 0111880|
|2019-01-16 13:41||Martin Friebe||Relationship added||related to 0034881|
|2020-06-27 17:12||nanobit||Note Added: 0123629|
|2020-06-27 21:07||Martin Friebe||Note Added: 0123633|
|2020-07-01 14:41||nanobit||Note Added: 0123700|
|2020-07-01 16:37||Martin Friebe||Note Added: 0123702|
|2020-07-01 17:50||nanobit||Note Added: 0123705|
|2020-07-01 18:30||Martin Friebe||Note Added: 0123706|