topic Enable Stack Traces in Intel® Fortran Compiler

Enable Stack Traces

Nick2 — Wed, 21 Apr 2010 01:56:45 GMT

Hello,

I'm trying to get stack traces every time my app crashes (eg. divide by zero). I have two configurations - one DOS, one DLL. The DOS one gives me a nicestack trace with no intervention, but the DLL, I use SEH.

Somehow I ended up disabling optimizations, at least in theDLL version (not good), and I'm still not getting what I want from the DLL...Settings below.

What I do get is DbgHelp.dll tries to load my .pdb file...in the directory where I originally compiled the .dll! So naturally, on every machine except the development machine, I can't get a nice stack trace when the DLL version crashes.

Any idea what I'm doing wrong to disable optimization and not have stack trace info in my dll?

(static library)

(DOS)

(DLL)

Enable Stack Traces

Stephen_D_Intel — Wed, 21 Apr 2010 19:59:48 GMT

Hello,

One difference is in your link step for the DLL: GenerateDebugInformation="true",
which will link against debug versions of the libraries. This could explain the
behavior of attempting to load the .pdb file. The debug libraries should not be
available on non-development machines because the debug libraries are not
redistributable.

Regards,
Steve D.
Intel Developer Support

Enable Stack Traces

Martyn_C_Intel — Thu, 22 Apr 2010 00:12:01 GMT

I'm not sure what you mean by the "DLL version" of your program.
To get a stack trace for floating-point exceptions such as divide-by-zero, you must unmask the exceptions (they are masked by default). You are doing that using the switch /fpe:0, or the equivalent property in the IDE. When your main program is compiled with this switch, the compiler inserts a call to set bits in the floating point control words to unmask divide-by-zero, overflow and floating invalid exceptions. However, this is not done for functions or subroutines other than the main program (it could cause a significant overhead if it was done for every call). So for your "DLL version", either ensure that it has a Fortran main program that is compiled with /fpe:0, or else unmask the desired exceptions by a call to the runtime library, such as FOR_SET_FPE, or by using the features of the IEEE_EXCEPTIONS module that was introduced in Fortran 2003. In thelatest compiler version, you may also use the option /fpe-all:0, which will unmask exceptions on entry to an individual subroutine, and restore the mask to its previous value on exit. This may incur some performance overhead.
Once exceptions are unmasked, the /traceback option should be sufficient to give astack traceafter a flaoting-pointexception, even for a non-debug build.

Enable Stack Traces

Nick2 — Thu, 22 Apr 2010 14:31:18 GMT

Steve, Martyn,

Thanks for the responses!

I did try to remove the GenerateDebugInformation="true" linker setting, but it did not make any difference.

Let me give you more info about how my DLL works, that may shed more light...

.NET GUI front end iteratively calls:
C++/CLI executable that transitions into native code, calls _controlfp_s and _set_se_translator, and then calls the Fortran DLL exported subroutine;
Fortran DLL then performs various calcs

So here's an example of a crash that I get with the Fortran Console configuration (without the fancy GUI or C++/CLI stuff) and another one that I get with the DLL configuration...

Again, when I run this on the development machine with my PDB file in the location where it was created, the DLL crash doesn't get SymGetModuleInfo and SymGetLineFromAddr failures, and instead of 0x05153520 [?]:EEEEE() [0x00542F0D] I would get 0x05153520 MODULENAME:SUBROUTINENAME() [0x00542F0D]

forrtl: error (65): floating invalid
Image PC Routine Line Source
GGGGGGG.exe 009F4049 _CCCCCC 1937 CCCCCC.FOR
GGGGGGG.exe 007007EC _AAA 1467 AAA.FOR
GGGGGGG.exe 004E05C1 _BBBBBB 107 BBBBBB.FOR
GGGGGGG.exe 004FE137 _DDDDDD 474 DDDDDD.FOR
GGGGGGG.exe 0042153A _MAIN__ 532 EEEEE.FOR
GGGGGGG.exe 00E50773 Unknown Unknown Unknown
GGGGGGG.exe 00E33C39 Unknown Unknown Unknown
kernel32.dll 7C817077 Unknown Unknown Unknown

Application crashed with error c00002b5: {EXCEPTION}
Multiple floating point traps.
0x05153520 [?]:EEEEE() [0x00542F0D]
SymGetModuleInfo failed with error 7e: The specified module could not be found.
SymGetLineFromAddr failed with error 1e7: Attempt to access invalid address.

0x05153520 [?]:EEEEE() [0x001B9AA8]
SymGetModuleInfo failed with error 7e: The specified module could not be found.
SymGetLineFromAddr failed with error 1e7: Attempt to access invalid address.

0x05153520 [?]:EEEEE() [0x0005DFC1]
SymGetModuleInfo failed with error 7e: The specified module could not be found.
SymGetLineFromAddr failed with error 1e7: Attempt to access invalid address.

0x05153520 [?]:EEEEE() [0x00086A47]
SymGetModuleInfo failed with error 7e: The specified module could not be found.
SymGetLineFromAddr failed with error 1e7: Attempt to access invalid address.

0x05153520 [?]:EEEEE() [0x00004C14]
SymGetModuleInfo failed with error 7e: The specified module could not be found.
SymGetLineFromAddr failed with error 1e7: Attempt to access invalid address.

0x10005BE0 [?]:LoadDllReturn0IfOK() [0x000075AE] <<<~~~~ This is my C++/CLI function
SymGetModuleInfo failed with error 7e: The specified module could not be found.
SymGetLineFromAddr failed with error 1e7: Attempt to access invalid address.

Enable Stack Traces

Steven_L_Intel1 — Thu, 22 Apr 2010 15:34:35 GMT

I believe that the second traceback, the one with the errors, is coming from the Visual C++ library. The Fortran traceback seems to be working properly. I'll be honest and say that I have never seen a traceback in the form you show with the [] characters.

Enable Stack Traces

Nick2 — Thu, 22 Apr 2010 16:39:55 GMT

Steve,

Yes! I am formatting andwriting the text outputin the second traceback (I need to store it for various purposes, so that's why getting it in the form of a MessageBox or Command Prompt output is not really useful). That's why I mentioned calling _set_se_translator. I am basically using the Microsoft/Windows dbghelp C++ library to walk the stack and create that output.

Nick

Enable Stack Traces

Steven_L_Intel1 — Thu, 22 Apr 2010 17:53:38 GMT

I see - I think. I am not familiar with using those interfaces. Are you sure the PDB file is relevant? As far as I know, version 11.1 and earlier does not use the PDB file for debug information by default. I would start with the failure of the SymGetModuleInfo call and see what's going on there.

Enable Stack Traces

Nick2 — Thu, 22 Apr 2010 21:37:43 GMT

Once I disabled Linker/GenerateDebugInfo as suggested earlier, the PDB file went away from my DLL release output folder.

BUT, now, even on my development machine, I can't get the stack trace (SymGetModuleInfo fails). I did disable the "omit frame pointers" optimization.

So let's try another theory: in what format is this info stored inside the DLL? Is it some Intel format thatrequires some Intel-equivalent function of SymGetModuleInfo and SymGetLineFromAddr ?

Enable Stack Traces

Steven_L_Intel1 — Fri, 23 Apr 2010 00:37:41 GMT

Yes, the Intel compiler does store traceback info in an Intel-specific format. We supply the routine TRACEBACKQQ to read this. You can use this from your exception handler by supplying the Windows exception pointer. Traceback is independent of debug info.