Debugging Multithreaded Programs

The debugging of multithreaded program discussed in this topic applies to both the OpenMP* Fortran API and the Intel Fortran parallel compiler directives. When a program uses parallel decomposition directives, you must take into consideration that the bug might be caused either by an incorrect program statement or it might be caused by an incorrect parallel decomposition directive. In either case, the program to be debugged can be executed by multiple threads simultaneously.

To determine the correctness of and debug multithreaded programs, you can use the following:

• For Linux and Mac OS systems, Intel® Debugger (IDB) or GDB.  

• For Windows systems, Microsoft Visual Studio* Debugger or the Intel Debugger   

• Intel Fortran Compiler debugging options and methods; in particular, -d-lines (Linux and Mac OS) or /d-lines (Windows)

• Intel® Thread Checker

There are important differences between a multithreaded debugger and a thread checker. The former allows the user to control the execution of a program to identify the bugs in a program, whereas the later uses program instrumentation to collect thread-related information during the program's execution, and then displays diagnoses on potential problems. A debugger is suitable for identifying programming bugs that can be reliably reproduced. A thread checker is especially useful for catching multithreaded bugs that are difficult to reproduce, such as dead locks and race conditions.

To debug the performance of multithreaded programs, you can use:

• Intel® Thread Profiler

• Intel VTune™ Performance Analyzer

Using IDB

Debugging a multithreaded program with IDB is similar to using it to debug a single-threaded program. First, set some breakpoints that may help you narrow down where a bug is occurring. Then run the process to the breakpoint and inspect the process state. Continue the process to successive breakpoints to determine the cause of the problem.

IDB also provides commands for debugging a multithreaded process; specifically, show thread, and thread. Additionally, the IDB commands stop, when, and where allow you to indicate a thread specifier to make them effective only to the threads that are specified.

IDB uses a "stop the world/all threads run" process control model. When a thread in a multithreaded process stops because of a breakpoint or an asynchronous event, IDB stops all the other threads in the process and issues the user prompt. Doing so ensures that the process state will stay constant for your inspection. When you resume a multithreaded process by issuing a mover command (for example, cont), all threads in the threads resume. The only exceptions are the stopi and nexti commands. These instruction-level mover commands resume only the thread that last triggered an event. They provide a finer level of control over the execution of a thread.

For debugging an OpenMP application, IDB provides the following commands to display information on OpenMP entities: show lock, show team, show thread, and show openmp thread tree.

Note

IDB support for OpenMP is not available on Mac OS systems.

For more information, refer to the IDB manual.

Using GDB

For more information, refer to Section 4.9 of the GDB manual.

Using the Microsoft Visual Studio Debugger

For more information, refer to the Visual Studio online help.