Debug win32 system exceptions in Lazarus apps
lazarus / 12-Debugger

----------------------------------------------------------------------
nanobit · 2019-04-03 09:50

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 · 2019-04-03 16:32

Quote from: nanobit on April 03, 2019, 11:50:34 amAlternatively, 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 · 2019-04-30 10:34

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][+][-]window.onload = function(){var x1 =
document.getElementById("main_content_section"); if (x1) { var x =
document.getElementsByClassName("geshi");for (var i = 0; i function
PascalException_Create: EExternal;var ExcObject:
EExternal;begin//emms; // moved behind fpuResetcase
SavedExc.ExceptionCode of  EXCEPTION_FLT_DIVIDE_BY_ZERO: begin   
fpuReset; emms;    ExcObject := EZeroDivide.Create('');  end; 
EXCEPTION_FLT_INEXACT_RESULT,  EXCEPTION_FLT_INVALID_OPERATION, 
EXCEPTION_FLT_STACK_CHECK: begin    fpuReset; emms;    ExcObject :=
EInvalidOp.Create('');  end;  EXCEPTION_FLT_OVERFLOW: begin   
fpuReset; emms;    ExcObject := EOverflow.Create('');  end; 
EXCEPTION_FLT_DENORMAL_OPERAND,  EXCEPTION_FLT_UNDERFLOW: begin   
fpuReset; emms;    ExcObject := EUnderflow.Create('');  end; 
EXCEPTION_INT_DIVIDE_BY_ZERO: begin    emms;    ExcObject :=
EDivByZero.Create('');  end;  EXCEPTION_INT_OVERFLOW: begin    emms; 
 ExcObject := EIntOverflow.Create('');  end; 
EXCEPTION_ACCESS_VIOLATION: begin    emms;    ExcObject :=
EAccessViolation.Create('');  end;  EXCEPTION_STACK_OVERFLOW: begin  
emms;    ExcObject := EStackOverflow.Create('');  end; 
EXCEPTION_PRIV_INSTRUCTION: begin    emms;    ExcObject :=
EPrivilege.Create('');  end;  EXCEPTION_ARRAY_BOUNDS_EXCEEDED: begin 
 emms;    ExcObject := ERangeError.Create('');  end;  else begin   
emms;    ExcObject := EExternalException.Create('');  end;end;

----------------------------------------------------------------------
nanobit · 2019-04-30 10:37

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

----------------------------------------------------------------------
th1975 · 2019-04-30 10:48

Quote from: nanobit on April 30, 2019, 12:37:35 pmSorry, 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.