[allenzhao]

Hi, All,

I am running a modified version of OpenFOAM 1.4.1 cross-compiled with MingW compiler on Windows, and we have a runtime error like:

forrtl: error (73): floating divide by zero

On Windows (MingW port) his error will get triggered with or without FOAM_SIGFPE being set.

The same source code compiled with Linux/gcc can run when FOAM_SIGFPE is NOT set, but will crash in the same location when FOAM_SIGFPE is set in the env.

So obviously, this is an issue with the Foam::sigFpe::set() implementation.

Is there any special gcc switch used in the Linux compilation that allows more tolerance to division by zero?

Any suggestions?

[mattijs]

OF on Linux does not set anything unless FOAM_SIGPFE is set so guess default behaviour is different. No special gcc flags are used except -O3.

All applications should run with FOAM_SIGFPE switched on anyway.

[gocarts]

It appears a MinGW compiled executable will raise a FPE by default, so I suggest modifying the Windows FPE code to respond to the FOAM_SIGFPE. For details visit:
http://www.symscape.com/openfoam-on-windows#comment-182

[allenzhao]

Hi, Richard,

Just tried the modification, but my colleague just told me that the fail-out error message is exactly the same.

What we did was just to update the file, and removed all the lib/<platform> directory, and force the linking of all the libraries.

Maybe that is not enough?

[gocarts]

Hi Allen,

I think your compiling strategy is fine - the dependency tracking works well enough that you could just recompile without forcing relinks.

I just tried forcing a floating point exception with details at:
http://www.symscape.com/openfoam-on-windows#comment-184

I found that the original version of sigFpe.C worked as expected according to the env FOAM_SIGFPE setting under Wine on Linux and Windows XP.

As I recall you are running OpenFOAM from within a fortran process - right? I wonder if that is causing a problem.

Have you tried running using a vanilla dos cmd console?

[allenzhao]

We got the same error when running from dos command.

I am reviewing the way how we build the mingw compiler: we download the vanila copy of the source code, but I have "enable_sjlj_exceptions=1" enabled for the build.

Could it be part of the issue? I guess I know too little about this sjlj exception thing - it may not be relevant at all.

[gocarts]

In building the cross compiler I did the same as you and also used the "--enable-sjlj-exceptions" option.

If it's any help I've posted a link to the MinGW cross compiler script I used at:
http://www.symscape.com/openfoam-on-windows

The link is within the sentence "I used the build-mingw script" which is part of stage 1 of the Patch Build Process.

[allenzhao]

It turns out that in order to use your implementation of sigFpe.C, I have to use the MingW compiler with "--enable-sjlj-exceptions".

We actually tried to disable the setjmp/longjmp option when compiling the mingw gcc, then we got these:

signals/sigFpe.C: In function 'void clearFpe()':
signals/sigFpe.C:52: error: '_clearfp' was not declared in this scope
signals/sigFpe.C:53: error: '_controlfp' was not declared in this scope
signals/sigFpe.C: In member function 'void Foam::sigFpe::set()':
signals/sigFpe.C:137: error: '_controlfp' was not declared in this scope
signals/sigFpe.C:139: error: '_EM_ZERODIVIDE' was not declared in this scope
signals/sigFpe.C:139: error: '_EM_INVALID' was not declared in this scope
signals/sigFpe.C:139: error: '_EM_OVERFLOW' was not declared in this scope
signals/sigFpe.C:140: error: '_MCW_EM' was not declared in this scope

So, it seems that these native Win32 fpe exception call is only available when setjmp/longjmp is enforced.

Don't know what it means though.

[gocarts]

This is to be expected, as the FPE exception trap in OpenFOAM uses the setjmp/longjmp mechanism.

If you want to pursue this route (disabling setjmp/longjmp) then comment out the body of the methods in signals/sigFpe.C to avoid the compile errors. However, I think you'll also have to address other exceptions within signals/*.C

[allenzhao]

Sorry, just get chance to come back to the topic.

I guess I have to describe some details about our application.

1) Our main executable is compiled on Windows using Intel ifort compiler, with /fpe0 or fpe1 options.

2) The executable will dynamically load the OpenFoam.dll when needed.

We found that that the Foam::sigFpe::set() is always called when the OpenFOAM.dll is loaded (using LoadLibrary()), but the Foam::sigFpe::sigFpeHandler does not get invoked at all. We reach this conclusion by writing a line at the beginning of each of the 2 functions. It is indeed true, though surprising that sigFpeHandler() was never invoked, with or without FOAM_SIGFPE set.

According to Intel's ifort documentation, with /fpe0, Intel compiler does install its own fp exception handler, though with /fpe1, the fp exception is "disabled". Is it possible that the usage of _controlfp here is conflicting with Intel's FP exception handling?

Some further observation:

1) with ifort /fpe0 (Intel FP exception is used), the application will crash with or without FOAM_SIGFPE set, in either case, sigFpeHandler does not seem to be invoked.

2) with ifort /fpe1 (Intel FP exception is supposed to get disabled), the application will continue to run with some warning when FOAM_SIGFPE is not set; but crash when FOAM_SIGFPE is set (still the cout inside sigFpeHandler does not seem to have any effect).

Is it possible that in above case, some intel provided FPE handlers are in action?

I know that these observations can be interpreted in many ways, but hopefully someone already has a solution for it.