Exception handling under IVF

[longden_loo]

Well, I got my __try/__except exception handling working the way I wanted on CVF, but when I tried the code under IVF, a test array-out-of-bounds condition generated a stack trace and aborted the program instead of returning control to the program.

I modified the __except to force a program continuation ...

__try {
fortran_driver();
__except ( 1 )
{
* stuff that's supposed to happen, but doesn't *
}

... but the except clause never seems to execute (program just aborts). For the C wrapper project, I have "Enable C++ Exceptions" set to "yes", and "Basic Runtime Checks" set to "Both", without any effect.

I noticed that on the same project in CVF where the exception is being handled correctly, there's a project setting for C/C++ | C++ Language | Enable exception handling ... and that item is enabled ... but I can't find the equivalent in IVF.

Anyone have a clue? Thx.

[drgfthomas]

I'd: set 'No Frame Pointers' to No, 'Incremental Linking' to No, and C/C++ Run Time Checks' to /RTCs.

Also, the LPEXCEPTION_POINTERS should be passed to C by reference.

Additionally, at program initialization do something like:

....

control = FPCW$NEAR +&

FPCW$53 +&

FPCW$INVALID +&

FPCW$ZERODIVIDE +&

FPCW$OVERFLOW +&

FPCW$UNDERFLOW +&

FPCW$DENORMAL +&

FPCW$INEXACT

call

SETCONTROLFPQQ(control)

FPE_MASK = FPE_M_TRAP_OVF +&

FPE_M_TRAP_DIV0 +&

FPE_M_TRAP_INV

FPE_STS = FOR_SET_FPE(FPE_MASK)

...

and you have to interface your FortranWrap as in

interface

subroutine FortranWrap[Alias:'_FortranWrap']() end subroutine FortranWrap end interface

...

[longden_loo]

Thx, I'll look into those items.

In the meantime, I took the GETEPTRS sample solution in IVF and converted it to a VS 6 workspace. I also changed the nature of the test so that the exception is essentially an array out of bounds (array subscript is zero) which occurs in function BONG, just before the original divide by zero condition.

The try/except in the main driver is coded with __except (1) to unconditionally capture an exception condition, and the ensuing __except clause (printing a msg and exit with cc=99) executes on CVF, but not on IVF, where the rebuilt solution instead gets an "unhandled exception" when the zero index array is referenced.

I also changed the IF* libs to DF* libs to make it work under CVF ... and changed them back for the IVF test. The zip of the combined solution/workspace is attached for anyone interested.

[longden_loo]

Settings are changed as suggested but it still doesn't work for me, and the small GETEPTRS.zip example I posted shouldn't even require a reference to the EXCEPTION_POINTERS because it's only trying (and failing) to capture an array-out-of-bounds exception without doing anything with the exception information. Likewise, I shouldn't need to do all the suggested program initializations because that appears to be related to floating point exceptions, and my test scenario is an OS related exception (invalid array bounds).

Would appreciate it if someone could look over that sample (which is build-ready for both CVF 6.6 and IVF 9.0), and tell me what I'm doing wrong in IVF, because the CVF build against the same code works as expected (an array subscript exception is detected and handled using the code block following the __except), but the IVF build aborts with an unhandled exception message.

Thx. Longden

[drgfthomas]

The SEHs that I use for IVF 9.1 and CVF 6.6C sucessfully handles any manner of error in complex applications, so long as it's a Windows exception (with apologies to Henry F. and Bill G). This includes memory-, debugger-, fp-, integer-, exception-relatedexceptions, the whole catastrophy.

Have you considered submitting your sample to Premier Support?

[longden_loo]

Unfortunately I let my support services lapse and it may be a while before I get funding again to resume that. Oh well ... it was all working so well until that point, but then that is Murphy's Law.

Is there a sample solution somewhere that demonstrates SEH (using __try/__except), or is the SIGNALQQ-based GETEPTRS the only exception-handling sample?

[drgfthomas]

Yes, CVF 6 as 6 samples on SEH, GETEPTRS among them. These are in C:Program FilesMicrosoft Visual StudioDF98SAMPLESEXCEPTIONHANDLING.

Remember you can do EH from C/C++ (its a Microsoft extention to the C/C++ standard(s), afterall, and Fortran 95 has no error handling other than GOTO 999 STOP). The definitive tutorial on this entire topic is J. Richter's 'Programming Applications for Microsoft Windows", 4th ed or later (Microsoft Press).

HTH

[longden_loo]

Thanks Gerry. I don't have the "SAMPLES" directory under DF98, so I must've elected not to install that originally. I'll have to wait till next week to get my hands on the install disk at the office (long Labor Day weekend). I'll let you know how that goes. Maybe I'll look up Richter's book in the meantime :)

- Longden

[longden_loo]

I got the "SAMPLES" directory from the CVF 6.6 disks and it looks like the VBVF1 workspace includes code to test for an array out of bounds condition (and a lot more). It builds to a DLL, so I wrote a small Fortran driver to call it and I now have this sample running successfully (including catching the targeted exceptions) on CVF.

However, it's not playing nice with me on converting to IVF. After converting the workspace to a solution and extracting the Fortran projects, I had to replace includes for IOSDEF.FOR with FOR_IOSDEF.FOR, but there's still a string of compiler errors relating to FOR$IOS_SUCCESS, FOR$IOS_FILNOTFOU, and FOR$IOS_MIXFILACC). My guess is that there's more and I just reached a display limit on the compile errors. I haven't converted the "USE DF*" lines with the resepective "USE IF*" lines ... should I? There's not always a one-to-one on those, and I understand some of them are still valid.

Has anyone else converted the VBVF1 workspace to IVF, and if so I'd like to know what changes had to be done (source and project settings).

Steve, there seems to be a lot of good stuff in the CVF 6.6 SAMPLESEXCEPTIONHANDLING ... I'm surprised more of that wasn't ported over and included in the IVF 9.0 distribution. Is that in the works?

[Steven_L_Intel1]

Yes, there will be dozens of samples in the next major release of the compiler. Some are ported from CVF (with bugs fixed!), some are new. I haven't looked at that particular one yet.

[longden_loo]

Thx.

In the meantime ... my kingdom for a simple (and working) SEH sample solution!

What's frustrating is that the SEH samples seem to work with little fuss on CVF, but it's been like pulling teeth on IVF. I have to believe it's just a project setting someplace, which is why I'd really like to see a working IVF solution.

[longden_loo]

As an example, here are two source files, a C main driver (using try/except) and a called Fortran routine which gets an array bounds exception (zero index).

====> main.c:
#include
#include
extern float ARRAYTEST ( int *) ;

int main()
{
float a;
int b = 0;

// Cause an array out of bounds error
__try {
a = ARRAYTEST ( &b ) ;
}
__except ( 1 )
{
printf("exception caught");
exit(99);
}
exit(0);
}


====> ARRAYTEST.f90:
REAL(4) FUNCTION ARRAYTEST(R1)
INTEGER R1
REAL(4) anum(2)

! Cause an array bounds exception
ARRAYTEST = anum(r1)

END FUNCTION

On CVF, the debugger steps thru the "exception caught" message, and exits with cc=99 as expected. But on IVF, the debugger registers an unhandled exception as soon as the ARRAYTEST=anum(r1) line is executed.

[Jugoslav_Dujic]

But on IVF, the debugger registers an unhandled exception as soon as the ARRAYTEST=anum(r1) line is executed.

Hmm. I tried a similar example and that doesn't match my observation. My findings, though, are not useful either: I took a casual look at disassembly output of statement (located in a dll):

i1(index) = 0

and it turns out that it evaluates to:

if (index_is_out_of bounds)

 call _for_emit_diagnostic !ugly message box

else

 assign zero where appropriate

end if

IOW, no "Array out of bounds" exception (0xC000008C) is raised. I find it kind of odd; maybe it can be regulated by environment variables. I do, hovever, have FOR_IGNORE_EXCEPTIONS set to TRUE and traceback turned off in the project settings. Setting FOR_DISABLE_DIAGNOSTIC_DISPLAY to TRUE doesn't help either -- the process simply dies after the debugger signals "Unhandled exception: User breakpoint".

Steve?

[drgfthomas]

I have no problem using SEH in IVF 9.1 in and out of the debugger.

Two cases:

1.two nonfatal and one fatal exception

Debug Output:

First-chance exception at 0x7c59bc81 in FcallsfDLL.exe: 0xC000008F: Floating-point inexact result.
'FcallsfDLL.exe': Loaded 'C:WINNTsystem32dbghelp.dll', Cannot find or open a required DBG file.
First-chance exception at 0x7c59bc81 in FcallsfDLL.exe: 0xC0000091: Floating-point overflow.
First-chance exception at 0x7c59bc81 in FcallsfDLL.exe: 0xC000008C: Array bounds exceeded.
The thread 'Win32 Thread' (0x7fc) has exited with code 18 (0x12).
The program '[2284] FcallsfDLL.exe: Native' has exited with code 18 (0x12).

Traceback Log:

Exception: Floating point inexact operation.
Image PC Routine Line Source
KERNEL32.dll 7C59BC81 Unknown Unknown Unknown
SimpleDLL.dll 00E04D08 _GenerateErrors 14 GenErrors.F90
SimpleDLL.dll 00E04EDE Unknown Unknown Unknown
SimpleDLL.dll 00E04BF2 _fMain 68 fMain.f90
FcallsfDLL.exe 004013D1 _FCALLSFDLLAPPLY@ 157 FcallsfDLL.f90
FcallsfDLL.exe 0040E955 Unknown Unknown Unknown
FcallsfDLL.exe 00404DFA Unknown Unknown Unknown
Exception: Floating point overflow.&nb sp;
Image PC Routine Line Source
KERNEL32.dll 7C59BC81 Unknown Unknown Unknown
SimpleDLL.dll 00E04D6E _GenerateErrors 16 GenErrors.F90
SimpleDLL.dll 00E04EDE Unknown Unknown Unknown
SimpleDLL.dll 00E04BF2 _fMain 68 fMain.f90
FcallsfDLL.exe 004013D1 _FCALLSFDLLAPPLY@ 157 FcallsfDLL.f90
FcallsfDLL.exe 0040E955 Unknown Unknown Unknown
FcallsfDLL.exe 00404DFA Unknown Unknown Unknown
Exception: Array bounds exceeded.
Image PC Routine Line Source
KERNEL32.dll 7C59BC81 Unknown Unknown Unknown
SimpleDLL.dll 00E04DD4 _GenerateErrors 18 GenErrors.F90
SimpleDLL.dll 00E04EDE Unknown Unknown Unknown
SimpleDLL.dll 00E04BF2 _fMain 68 fMain.f90
FcallsfDLL.exe 004013D1 _FCALLSFDLLAPPLY@ 157 FcallsfDLL.f90
FcallsfDLL.exe 0040E955 Unknown Unknown Unknown
FcallsfDLL.exe 00404DFA Unknown Unknown Unknown

Information Application: The last exception was fatal and the application is closing
Information Application: Closed FortranSEH on 6/ 9/2006 at 8:51:42 AM

2. three nonfatal exceptions

Debug Output:

First-chance exception at 0x7c59bc81 in FcallsfDLL.exe: 0xC000008F: Floating-point inexact result.
'FcallsfDLL.exe': Loaded 'C:WINNTsystem32dbghelp.dll', Cannot find or open a required DBG file.
First-chance exception at 0x7c59bc81 in FcallsfDLL.exe: 0xC0000091: Floating-point overflow.
First-chance exception at 0x7c59bc81 in FcallsfDLL.exe: 0xC000008C: Array bounds exceeded.
The thread 'Win32 Thread' (0x8dc) has exited with code 0 (0x0).
The program '[2240] FcallsfDLL.exe: Native' has exited with code 0 (0x0).

Traceback Log:

Exception: Floating point inexact operation.
Image PC Routine Line Source
KERNEL32.dll 7C59BC81 Unknown Unknown Unknown
SimpleDLL.dll 00E04D08 _GenerateErrors 14 GenErrors.F90
SimpleDLL.dll 00E04EDE Unknown Unknown Unknown
SimpleDLL.dll 00E04BF2 _fMain 68 fMain.f90
FcallsfDLL.exe 004013D1 _FCALLSFDLLAPPLY@ 157 FcallsfDLL.f90
FcallsfDLL.exe 0040E955 Unknown Unknown Unknown
FcallsfDLL.exe 00404DFA Unknown Unknown Unknown
Exception: Floating point overflow.& nbsp;
Image PC Routine Line Source
KERNEL32.dll 7C59BC81 Unknown Unknown Unknown
SimpleDLL.dll 00E04D6E _GenerateErrors 16 GenErrors.F90
SimpleDLL.dll 00E04EDE Unknown Unknown Unknown
SimpleDLL.dll 00E04BF2 _fMain 68 fMain.f90
FcallsfDLL.exe 004013D1 _FCALLSFDLLAPPLY@ 157 FcallsfDLL.f90
FcallsfDLL.exe 0040E955 Unknown Unknown Unknown
FcallsfDLL.exe 00404DFA Unknown Unknown Unknown
Exception: Array bounds exceeded.
Image PC Routine Line Source
KERNEL32.dll 7C59BC81 Unknown Unknown Unknown
SimpleDLL.dll 00E04DD4 _GenerateErrors 18 GenErrors.F90
SimpleDLL.dll 00E04EDE Unknown&nbs p; Unknown Unknown
SimpleDLL.dll 00E04BF2 _fMain 68 fMain.f90
FcallsfDLL.exe 004013D1 _FCALLSFDLLAPPLY@ 157 FcallsfDLL.f90
FcallsfDLL.exe 0040E955 Unknown Unknown Unknown
FcallsfDLL.exe 00404DFA Unknown Unknown Unknown

Information Application: FortranSEH module closed on 6/ 9/2006 at 9: 2:34 AM

[longden_loo]

We're constrained to using IVF 9.0.28, so maybe that's an issue. Do you know if your app works under 9.0? Is your app's solution/project/source something you can post or email to me so I can examine the project settings?

I'm attaching the ARRAYTEST example above as a zip file which contains both the IVF 9.0 solution (.sln) and the CVF 6.6 workspace (.dsw) for anyone who want to test this for themselves. On CVF, the program correctly exits with a cc=99, but on IVF it generates an unhandled exception.

For CVF, open sehtest.dsw, "driver" is the active project ... just clean, build "driver.exe" and run the debugger.

For IVF, open sehtest.sln. Clean solution, build solution, and run Debug on the "driver" project.

- Longden

[Jugoslav_Dujic]

Gerry, neither do I (I tried Access violation rather than FP one, successfully caught in C++ caller); however, the issue at hand is related only with Array out of bounds problem -- the exception doesn't seem generated at all, but handled in quite another way in latest IVF versions (cf. the revived "STOP in DLL" thread). I'm interested about the rationale.

[Steven_L_Intel1]

I'll have to check with the people who work more closely with this code, but my understanding is that in order to provide more detailed information about the bounds error the compiled code calls an RTL routine to emit a text message and it then calls DebugBreak to break into the debugger. This means that there is no array bounds exception to trap.

[Jugoslav_Dujic]

I kind of suspected that was the rationale, but it also breaks some compatibility. While I don't know the gory details, what's wrong with throwing "Array bounds exceeded" exception instead of DebugBreak? When debugging, both have essentially the same effect, and when not, it gives the caller a chance to survive if it catches it.

[Steven_L_Intel1]

This would require that the compiler tell the RTL that it was an array bounds error. Perhaps it knows - I'll ask. I don't know how easy it is for the RTL to raise that exception in a meaningful way.

[drgfthomas]

Jugoslav, I can't follow the dialog on this between you and Steve but then again I know or could less about the inners of compilers preferring to pay the big bucks to those who do. FWIW,in Debugger/Exceptions/Win32Exceptionsall selectedexceptions break into the debuger when thown,irrespective of whether or notit is handled. When thrown, a messagebox appears withbreak/continue/ignore options. Since SEH is in place, one sees the offending line of code and chooses to continue. If it's a fatal exceptionI call into the C-Fortran wrapper to quit (no STOP here) so I can fix the code. Isn't this how it's supposed to work?

[Steven_L_Intel1]

In ifort, array bounds violations do not raise exceptions, so you cannot use SEH or even the Exceptions dialog in the debugger to change the behavior. When an array bounds violation occurs, the RTL displays a detailed message and then calls DebugBreak so that a program running under the debugger can stop at the point of error. I think this looks like "User breakpoint", and occurs only when a debugger is loaded.

I was discussing this with some of the developers at lunch today and I have been asked to write up a "feature request" for some mechanism to allow applications to get some sort of hook into the ifort RTL's error reporting process. What I envision is the ability to specify a callback routine which is called just before the error would be displayed - the called routine could choose to do something else (display a different message to the user, log it, etc.) and then return to the RTL with a status of what to do next (go ahead and display message, don't display, etc.) Clearly the called routine would need some reasonable way of figuring out what kind of error had occurred, so it could choose whether or not to act. One might also envision a way to allow multiple such handlers in a chain. We're not going to reinvent SEH here (the Fortran standards committee has been unable to come to agreement on that issue.)

The issue of "continue" is thorny. In many cases, an error is non-continuable. We need to look at all the possible cases and think about what mechanisms make sense. We have the benefit of knowing about mechanisms used successfully on VMS, where the OS was designed for such things, so we know what we're aiming for.

No promises and no timeframes. But we are interested.