Debug win32 system exceptions in Lazarus apps

[nanobit]

For win32 system exceptions (AV, divByZero, ...) under debug mode, Lazarus currently has no solution.
The following article essentially says, UnhandledExceptionFilter (the only handler in win32LazApp) will never work in debugMode, but only in releaseMode.
https://devblogs.microsoft.com/oldnewthing/?p=94106

To improve debugging with win32 system exceptions,
I created a small unit (uses VEH) which works by simple addition to uses clause of projects.
I have to move on with my other works now, but this idea is very useful and should not become lost.
The community may improve it or/and derive from it freely. The original ideas came from this thread:
https://bugs.freepascal.org/view.php?id=12974

Alternatively, win32 SEH (much more complex) would also cover this need, but only if completely implemented and tested.
FPC_USE_WIN32_SEH is not defined, maybe it's incomplete, maybe no one is working on it.
Without official support, using fpc built with -dTEST_WIN32_SEH remains a shot in the dark.
If there is a plan, please let the community know:) See:
https://bugs.freepascal.org/view.php?id=28756

**************************************
The file win32Veh.pas is for building win32 binaries with fpc 3.0.x (non-SEH):
1) for debug-builds run under debugger: on system-exception: to continue to finally/except
2) for release-dlls to catch dll system-exceptions in finally/except in dll, to protect the host from faulty states and termination.
File update: 2019-05-20

[Martin_fr]

Alternatively, win32 SEH (much more complex) would also cover this need, but only if completely implemented and tested.

https://bugs.freepascal.org/view.php?id=34881

[th1975]

There seems to be an issue when using this and an FPU exception occurrs:
function PascalException_Create: EExternal;             
calls emms first.

During debuging it looks like emms re-triggers the FPU exception. As far as I understand the x86 assembler documentation, this is to be expected (not my specialty )
I have tried to move the emms to after the fpuReset call for all the FPU exceptions in PascalException_Create, and this seems to work.

Code: Pascal  [Select][+][-]

1. function PascalException_Create: EExternal;
2. var ExcObject: EExternal;
3. begin
4. //emms; // moved behind fpuReset
5. case SavedExc.ExceptionCode of
6.   EXCEPTION_FLT_DIVIDE_BY_ZERO: begin
7.     fpuReset; emms;
8.     ExcObject := EZeroDivide.Create('');
9.   end;
10.   EXCEPTION_FLT_INEXACT_RESULT,
11.   EXCEPTION_FLT_INVALID_OPERATION,
12.   EXCEPTION_FLT_STACK_CHECK: begin
13.     fpuReset; emms;
14.     ExcObject := EInvalidOp.Create('');
15.   end;
16.   EXCEPTION_FLT_OVERFLOW: begin
17.     fpuReset; emms;
18.     ExcObject := EOverflow.Create('');
19.   end;
20.   EXCEPTION_FLT_DENORMAL_OPERAND,
21.   EXCEPTION_FLT_UNDERFLOW: begin
22.     fpuReset; emms;
23.     ExcObject := EUnderflow.Create('');
24.   end;
25.   EXCEPTION_INT_DIVIDE_BY_ZERO: begin
26.     emms;
27.     ExcObject := EDivByZero.Create('');
28.   end;
29.   EXCEPTION_INT_OVERFLOW: begin
30.     emms;
31.     ExcObject := EIntOverflow.Create('');
32.   end;
33.   EXCEPTION_ACCESS_VIOLATION: begin
34.     emms;
35.     ExcObject := EAccessViolation.Create('');
36.   end;
37.   EXCEPTION_STACK_OVERFLOW: begin
38.     emms;
39.     ExcObject := EStackOverflow.Create('');
40.   end;
41.   EXCEPTION_PRIV_INSTRUCTION: begin
42.     emms;
43.     ExcObject := EPrivilege.Create('');
44.   end;
45.   EXCEPTION_ARRAY_BOUNDS_EXCEEDED: begin
46.     emms;
47.     ExcObject := ERangeError.Create('');
48.   end;
49.   else begin
50.     emms;
51.     ExcObject := EExternalException.Create('');
52.   end;
53. end;  

                         

[nanobit]

Sorry, was the wrong file. Could you download again?

[th1975]

Sorry, was the wrong file. Could you download again?

Downloaded again, and I can confirm that the updated file fixes the issue.

Thank you btw. for pointing me this way in the other thread in the freepascal bugtracker! Right now it looks like your unit (with the preferBuiltinTraps define removed and some conditionals added for future 32-bit SEH compatibility and present 64-bit SEH compatibility) will be the fix for my problem.