Recording Operating System Counters

Similar to recording of process specific counters, Intel® Trace Collector can record operating system counters, which provide information about a node. In contrast to the process specific counters, OS counters are sampled very infrequently by one background thread per node and thus the overhead is very low. The amount of trace data also increases insignificantly.

By default, recording of OS counters is disabled. To enable it, set the configuration option:

Tracing Library Calls

If you have an application that makes heavy use of libraries or software components developed independently, you may want to exclude the information not related directly to your application from the trace data. At the same time, the library developer might want to do the opposite – trace only data related to their library.


Running with Valgrind*

For distributed memory checking (LOCAL:MEMORY:INITIALIZATION) and detecting illegal accesses to memory owned by MPI (LOCAL:MEMORY:ILLEGAL_ACCESS) it is necessary to run all MPI processes under control of the Valgrind* memory checker (version 3.2.0 or higher). See for more information.



You can configure manually which errors are checked: all errors have a unique name and are categorized in a hierarchy similar to functions. For example, LOCAL:MEMORY:OVERLAP is a local check which ensures that memory is not used twice in concurrent MPI operations. By disabling certain errors you can skip a report about it and reduce the checking overhead.


Analyzing the Results

For interactive debugging, you should start the application so that stderr is printed to a console window. Then you can follow which errors are found while the application is running and start analyzing them without having to wait for it to complete. If critical errors are found early, you can abort the run, fix the problem and restart. This ensures a much faster code and test cycle than a post-mortem analysis.


TotalView* Debugger

For TotalView* Debugger, it is necessary to pay attention that the breakpoint should be set for all processes. There are several ways to automate procedure of setting breakpoints. Mostly it depends on how commonly it is planned to use this automation.

If it is planned to apply it only for the current program, you can create the file filename.tvd (file name being the name of the executable) in the working directory in advance and put the following line into it:


GNU* Symbolic Debugger

To automate the procedure of setting breakpoints, GNU* Symbolic Debugger (GDB) supports executing commands automatically. To apply setting this breakpoint for all programs in the current working directory, you can create a file .gdbinit with the following lines (or add them if it already exists):

Produktunterlagen abonnieren