View Issue Details

IDProjectCategoryView StatusLast Update
0016801FPCCompilerpublic2013-11-28 22:05
ReporterGrant AllanAssigned ToFlorian 
PrioritynormalSeverityminorReproducibilityalways
Status closedResolutionfixed 
PlatformEM64T / AMD64OSWindowsOS Version7
Product Version2.2.4Product BuildLazarus 0.9.28.2 beta, svn 22279 
Target VersionFixed in Version2.6.0 
Summary0016801: loading FPC dll messes with host app's floating-point exception flags
DescriptionMy host app is written in fortran. I am loading the DLL at runtime using LoadLibrary. Before the LoadLibrary call, my 8087 control word is $33F. After the LoadLibrary call, the control word is $332.

I feel very lucky that I managed to narrow it down to this - if I was not using the LoadLibrary method of loading the DLL, I may never have found it. This might cost some other programmer many hours of frustration.

I have added fortran code to query the control word before LoadLibrary, and then restore it afterwards. It seems to work OK for the debug build of my fortran application. But for the release build of my fortran app I end up with heap corruption message from windows; it tells me that I have a bug in either my host application or one of the DLLs it has loaded.
Steps To Reproduce1) write an application in fortran, using compiler setting to generate NaNs instead of throwing floating point exceptions
2) write a DLL with lazarus
3) in the fortran, add a call LoadLibrary, and code to query the 8087 control word before and after the call.
Additional InformationThe lazarus DLL and the fortran exe are both 64-bit. So I'm not really sure how legitimate it is for me to be messing with the 8087 control word at all, because I have read that doing so is IA32-specific??? So, even though un-blatting the control word seemed to fix the problem for my debug build of the Fortran exe, maybe that was just lucky?
TagsNo tags attached.
Fixed in Revision
FPCOldBugId
FPCTarget
Attached Files

Relationships

related to 0016263 resolvedJonas Maebe SSE Floating point exceptions not masked 

Activities

Grant Allan

2010-06-28 01:09

reporter   ~0038844

Please don't worry about the heap corruption mentioned in the original post. The heap corruption occurs even then I don't load the Lazarus DLL, so it must be a separate problem.

Florian

2010-07-03 23:24

administrator   ~0038987

Please read my last comment in http://bugs.freepascal.org/view.php?id=16263 why the dll startup code has to reset the fpu cw. The proper solution is to set the fpu cw in the dll init code as you need it.

Grant Allan

2010-07-05 05:17

reporter   ~0039014

I don't understand why this is set to resolved, no change required. I don't really understand much of the comment about "it must be this way to be delphi compatible" either.

I have a 32-bit delphi-built version of my DLL, which runs fine with a 32-bit version of my Fortran app - i.e. the delphi DLL does not trash my 8087 control word.

It is the 64-bit version of the DLL, built by Lazarus because delphi cannot do 64-bit, which has the problem.

Yet the explanation of why it has to be this way, is because of compatibility with how delphi works??? How can that be?

Florian

2010-07-05 08:36

administrator   ~0039021

As explained in the other bug report, there are multiple reasons why it is done as it is done.

By default FPC is not perfectly delphi compatible: only the behaviour in case of exceptions is the same. To get the same behaviour with delphi and fpc: just mask the exceptions in your dll init code as needed. Due to the global exception masking of x86 CPUs there is no way to satisfy everybody needs.

If you need further assistence, please discuss the matter on the mailing lists.

Florian

2010-07-05 08:41

administrator   ~0039023

Add: Since it is common that dlls modify the fpu status word when being load, fpc has a SafeLoadLibrary call. Maybe something similiar is available in other languages as well.

Jonas Maebe

2010-11-14 17:02

manager   ~0043038

In FPC 2.5.1, the fpu control word is now no longer changed in the init code of dynamic libraries.

Issue History

Date Modified Username Field Change
2010-06-28 00:58 Grant Allan New Issue
2010-06-28 01:09 Grant Allan Note Added: 0038844
2010-06-28 11:18 Jonas Maebe Relationship added related to 0016263
2010-07-03 23:24 Florian Note Added: 0038987
2010-07-03 23:24 Florian Status new => resolved
2010-07-03 23:24 Florian Resolution open => no change required
2010-07-03 23:24 Florian Assigned To => Florian
2010-07-05 05:17 Grant Allan Status resolved => feedback
2010-07-05 05:17 Grant Allan Resolution no change required => reopened
2010-07-05 05:17 Grant Allan Note Added: 0039014
2010-07-05 08:36 Florian Status feedback => resolved
2010-07-05 08:36 Florian Resolution reopened => fixed
2010-07-05 08:36 Florian Note Added: 0039021
2010-07-05 08:41 Florian Note Added: 0039023
2010-11-14 17:02 Jonas Maebe Note Added: 0043038
2013-11-28 22:05 Jonas Maebe Status resolved => closed
2013-11-28 22:05 Jonas Maebe Fixed in Version => 2.6.0