View Issue Details

IDProjectCategoryView StatusLast Update
0028756FPCCompilerpublic2020-01-10 19:06
ReporterAndrey ParamonovAssigned ToJoost van der Sluis 
PrioritynormalSeverityminorReproducibilityN/A
Status resolvedResolutionfixed 
Platformx86OSWindowsOS Version
Product Version3.0.0Product Build 
Target Version3.2.0Fixed in Version3.3.1 
Summary0028756: Enable Win32 SEH by default
DescriptionFreePascal 3.0 introduces reworked exception machinery on Windows x86-64 (using SEH), which fixes numerous bugs:
0024012: Enable Win64 SEH by default so exceptions in DLLs can properly be caught.
http://bugs.freepascal.org/view.php?id=24012

Similar problems existed on Windows x86, and similar patch is available for this platform:
0025363: win32 per thread SEH implementation.
http://bugs.freepascal.org/view.php?id=25363
However, the latter patch is only available under non-default FPC compiler option. The commit message is:

+ SEH support for Win32. Enable by cycling with OPT=-dTEST_WIN32_SEH.

Although basic things work (no regressions in test suite, also with TEST_OPT=-O2), there are some secondary issues/TODOs:
- Exception frame around PASCALMAIN is not properly removed in DLLs
- No stack traces yet
- Stack overallocated in finalizer procedures, their entry/exit code needs cleanup
- Signals unit is probably completely broken.

It is proposed that remaining issues are investigated and fixed/discarded, so Windows on x86 could benefit from SEH exceptions being on by default.
TagsNo tags attached.
Fixed in Revision
FPCOldBugId
FPCTarget-
Attached Files

Relationships

related to 0012974 resolvedJoost van der Sluis FPC can't catch windows exceptions (av's) in a try/except in a dll call 
parent of 0030205 closedSven Barth [Win32-SEH] Internal error 201201143 when dealing with managed locals in subroutine 
related to 0036550 new The signals units is broken on Win32/Win64 (when SEH-exceptions are being used) 

Activities

Cyrax

2015-09-30 20:32

reporter   ~0086189

>- No stack traces yet
Care to elaborate on this? I have not found any problems on them when doing programming with SEH enabled 32-bit FPC.

Andrey Paramonov

2015-10-01 10:00

reporter   ~0086196

Neither did I, so far :-)

The text above
---
+ SEH support for Win32. Enable by cycling with OPT=-dTEST_WIN32_SEH.

Although basic things work (no regressions in test suite, also with TEST_OPT=-O2), there are some secondary issues/TODOs:
- Exception frame around PASCALMAIN is not properly removed in DLLs
- No stack traces yet
- Stack overallocated in finalizer procedures, their entry/exit code needs cleanup
- Signals unit is probably completely broken.
---
is the verbatim commit message. Commit is by Sergei Gorelkin:
http://bugs.freepascal.org/view_user_page.php?id=571

I'm not sure how actual, severe and "x86 SEH"-specific listed issues are. At least "signals unit" item seems to be related to x86-64 SEH as well.

Sergei Gorelkin

2015-10-01 15:00

developer   ~0086199

The commit message for r26225 contains only issues that were apparent at that moment. A number of further issues were detected and fixed, which can be found by examining the svn history of rtl/win32 directory. From the original issues, only the stack traces were added in r27146, rest remain untested.
In general, on each attempt of closer testing, some issue popped up. Therefore I don't consider Win32 SEH production ready yet, at least not for 3.0.

The issue with signals unit does not apply to win64, because win64/signals.pp is a blind copy-paste from win32 counterpart that never worked - so it cannot be broken.

Jonas Maebe

2015-10-01 15:31

manager   ~0086200

Isn't this issue essentially a duplicate of 0012974 ?

jamie philbrook

2016-10-03 02:09

reporter   ~0094934

If this means anything. A recent app set to a Win64(64bit Laz) Target will crash a TOpenFileDialog If I browse to a EXE file that Windows deems broken.

 The fix is to turn off the DLL(Lib) exceptions in the options of Lazarus.
on my system (Win10), I have virus scanner and Defender operating, if that means
anything?

Joost van der Sluis

2020-01-10 19:06

manager   ~0120311

With issue 0012974 being resolved, and the issue with the signals-unit being reported in a separate issue (0036550), I consider this one resolved.
The stack might be 'over-allocated', but even when this is the case, this is more a possible optimization then a bug.

Issue History

Date Modified Username Field Change
2015-09-30 09:41 Andrey Paramonov New Issue
2015-09-30 20:32 Cyrax Note Added: 0086189
2015-10-01 10:00 Andrey Paramonov Note Added: 0086196
2015-10-01 15:00 Sergei Gorelkin Note Added: 0086199
2015-10-01 15:31 Jonas Maebe Note Added: 0086200
2016-10-02 23:43 Jonas Maebe Relationship added parent of 0030205
2016-10-03 02:09 jamie philbrook Note Added: 0094934
2018-06-23 10:54 Jonas Maebe Note View State: 0086200: private
2018-06-23 10:54 Jonas Maebe Note View State: 0086200: public
2018-07-07 12:45 Marco van de Voort Relationship added related to 0012974
2019-12-18 16:51 Marco van de Voort Target Version => 3.2.0
2019-12-18 16:51 Marco van de Voort FPCTarget => -
2019-12-30 15:09 Joost van der Sluis Assigned To => Joost van der Sluis
2019-12-30 15:09 Joost van der Sluis Status new => assigned
2020-01-10 19:03 Joost van der Sluis Relationship added related to 0036550
2020-01-10 19:06 Joost van der Sluis Status assigned => resolved
2020-01-10 19:06 Joost van der Sluis Resolution open => fixed
2020-01-10 19:06 Joost van der Sluis Fixed in Version => 3.3.1
2020-01-10 19:06 Joost van der Sluis Note Added: 0120311