View Issue Details
|ID||Project||Category||View Status||Date Submitted||Last Update|
|0016801||FPC||Compiler||public||2010-06-28 00:58||2013-11-28 22:05|
|Reporter||Grant Allan||Assigned To||Florian|
|Platform||EM64T / AMD64||OS||Windows||OS Version||7|
|Product Version||2.2.4||Product Build||Lazarus 0.9.28.2 beta, svn 22279|
|Target Version||Fixed in Version||2.6.0|
|Summary||0016801: loading FPC dll messes with host app's floating-point exception flags|
|Description||My 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 Reproduce||1) 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 Information||The 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?|
|Tags||No tags attached.|
|Fixed in Revision|
||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.|
||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.|
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?
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.
||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.|
||In FPC 2.5.1, the fpu control word is now no longer changed in the init code of dynamic libraries.|
|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|