Tips for Debugging Run-time Failures in Applications Built with the Intel® Fortran Compiler
Your app builds successfully, but crashes at runtime. What Next? Try some useful Intel compiler diagnostic options before launching into lengthy debugger sessions.
1) Build with /traceback (Windows*) or –traceback (Linux* or MacOS*).
This can give a stack trace with subroutine or function names, source filenames and line numbers at the point of failure, if it is in user code, without the need to build with debug symbols. This is designed as a lightweight option that can also be left enabled for release builds. If an end user encounters a problem, the traceback can be a starting point for a bug report.
2) Build with /gen-interfaces /warn:interfaces (Windows) or –gen-interfaces –warn interfaces (Linux or MacOS). This is able to detect at compile time many instances of argument mismatches between caller and callee, which can otherwise lead to hard-to-debug runtime failures. These options automatically create and check explicit, Fortran90-style interfaces for Fortran77-style or other code that does not already have them. There is no impact on run-time performance.
3) Try building and running with /check (Windows) or –check (Linux and MacOS).
This instruments your code and makes a number of valuable run-time checks, including array bounds checking, array shape checking, checking for uninitialized or disassociated pointers, and for some types of uninitialized local scalar variables. Bounds checking in particular is likely to make your program run slower.
4) Build your program, including the main routine, with /fpe:0 (Windows) or –fpe0 (Linux or MacOS). This will cause your program to halt if it encounters a divide-by-zero, overflow or invalid floating-point exception, instead of generating a NaN (not-a-number) and silently continuing. If you have also specified /traceback (-traceback), you should be able to see where the floating point exception occurred. Any impact on performance is likely to be small.
5) If your application fails early on with a segmentation fault, you might be exceeding the default maximum stack size. On Linux or MacOS, try setting
ulimit –s unlimited (bash) or limit stacksize unlimited (C shell)
On Windows, use the /F build option or increase the stack limits in the IDE under project properties/linker/system/ Stack Commit Size and Stack Reserve Size.
6) Use the compiler provided interfaces. If you call run-time library functions, build with
USE IFLPORT
If you call OpenMP run-time library functions, compile with
USE OMP_LIB
If you call functions from MKL, USE the corresponding module.
7) Look carefully for any error messages in your output log file. Errors from the Fortran run-time library include an error number. Additional information about such RTL (run-time library) errors may be found in the main compiler documentation under “List of Run-Time Error Messages”, or by searching for the error number directly.
8) If you are building an application using OpenMP*, check out the advice under Tips for Debugging OpenMP Apps.
All the above options may be used with release (optimized) builds. Certain options are enabled by default in a debug build made through the Microsoft* Visual Studio* IDE on Windows.
Additional information may be found in the compiler documentation in the section “Understanding Run-Time Errors” and the references therein; also in the article Determining Root Cause of Segmentation Faults or SIGBUS Errors
9) OK, sometimes you need to do the heavy lifting. If these suggestions haven’t helped, or if they helped localize the problem but you need more information, it may be time to start interactive debugging. Check the compiler documentation for information on the debuggers available.