View Issue Details

IDProjectCategoryView StatusLast Update
0034502LazarusDebuggerpublic2020-07-01 18:30
Reporternanobit Assigned ToMartin Friebe  
Status assignedResolutionopen 
Product Version2.1 (SVN) 
Summary0034502: Lazarus WIN32_SEH debugging with F8
DescriptionI 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).
TagsNo tags attached.
Fixed in Revision
Attached Files


related to 0034881 feedbackSven Barth FPC Request debug info for SEH (finally/except) to prevent regression when win32 switches to SEH 


Martin Friebe

2018-11-08 16:04

manager   ~0111865

Last edited: 2018-11-08 16:05

View 2 revisions

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:= 2;
    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).

F9 works.
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


2018-11-09 11:59

reporter   ~0111880

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.


2020-06-27 17:12

reporter   ~0123629

Tested with FpDebug: When I set a breakpoint on "jmpl *%ecx" in,
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())

Martin Friebe

2020-06-27 21:07

manager   ~0123633

>> 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.


2020-07-01 14:41

reporter   ~0123700

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().

Martin Friebe

2020-07-01 16:37

manager   ~0123702

Not intentionally.
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.


2020-07-01 17:50

reporter   ~0123705

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.

Martin Friebe

2020-07-01 18:30

manager   ~0123706,50403.0.html

Issue History

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