Though it is likely that Intel Inspector XE 2013 can find any memory or threading errors present in the code paths exercised in applications when run at the highest levels of analysis, there is no guarantee that Intel Inspector XE 2013 will find all memory and threading errors in your program.

We recommend starting with static analysis to remove as many issues as possible at compilation time and, then move to memory checking to find and fix memory issues and finally, to thread checking to find and fix threading issues which are usually hard to find and fix. If the application has race conditions, it’s possible that a fix for an incorrect access found by memory checking could be accomplished by resolving the race condition, which can only be detected by thread checking. It might also be the case that when running under memory checking, because it can alter scheduling and timing, a latent deadlock in the code might occur. Fixing the deadlock issue (which may be reported by thread checking), would enable a full run of the application under memory checking.

No. Intel® Inspector XE 2013 memory checking and thread checking tools instrument and analyze your program binaries dynamically. You don’t need to recompile or rebuild your programs. We recommend use of debug binaries or release binaries with debug information, so that error reports can be attributed to source code locations.

Static analysis operates differently. See our static analysis page for details.

No, they are injected into your program’s address space at runtime.

No, the current Intel® Inspector XE 2013 does not support process attach or detach. In order to find multithreaded bugs in your process, Intel® Inspector XE 2013 has to monitor memory initialization events (memory checking) or synchronization events (thread checking) from the start of the program.

Of course, you can always stop Intel® Inspector XE 2013 manually at any time after analysis starts.

The Intel® Inspector XE 2013 interactive debugging feature allows you to use a standard debugger to investigate memory or threading problems found by Intel® Inspector XE 2013. It supports Microsoft* Visual Studio 2008 & Visual Studio 2010 debugger (Microsoft* Visual Studio 2012 support is coming) on Windows* OS and the Intel and GNU debuggers on Linux* OS.

It’s not that simple. Intel® Inspector XE 2013 does a binary runtime analysis of your application, which means there is analysis code executing part of the time, not just your application’s code. You can attach a debugger to this, but you would be looking at the analysis tool’s code much of the time and learn nothing about the problem the tool reported was in your code.

When debugging without memory or threading analysis, a code breakpoint will stop execution at the right location, but that location might be executed thousands of times before the conditions are right that resulted in the problem being reported. By combining debug with analysis, the tool does the work of determining when the problem conditions have occurred and stops at the right time as well as location.

On the Windows* OS when integrated with the Microsoft Visual Studio* IDE, the debug feature is accessible at two points: from the context-sensitive menu when viewing the list of problems in a result and when setting up a new analysis. On the Linux* OS when using the Intel® Inspector XE 2013 Standalone GUI, the debug feature is accessible in the same manner.

It is also available from the Linux* command line using the –appdebug or –debug-this options on the –collect action. Debugging during analysis is not available from the Intel® Inspector XE 2013 Standalone GUI or command line interface on the Windows* OS.

The most likely reason to use debug during an analysis is after you have examined the call stacks and code surrounding a particular memory or threading problem reported by Intel® Inspector XE 2013 and find you need more information to determine the cause, such as what the application’s variables hold at that point or what’s happening in other threads. Selecting Debug This Problem on the problem of interest returns you to that point of execution as quickly as possible since the analysis being done can be reduced in many cases.

Perhaps you want to check for errors in a particular section of an application that takes a long time to execute and the exclusion options do not provide the granularity level you’d like. You can reduce the time it takes to execute to the point within a module where you want error checking to begin by setting a code breakpoint and starting the run with the analysis off. When checking for threading errors, this technique is only efficient if the area chosen for analysis is quite small compared to the overall execution time when under analysis. Threading analysis optimization cannot be done during an analysis with debug enabled, leading to extremely slow execution. Running the complete analysis without debug may be faster than using the debug method to limit the area being analyzed. Checking for memory errors does not have this issue.

If you are looking for memory errors in an application for the first time and want the ability to debug in each problem as it is reported, then enabling the debugger with analysis from the start is what you want. As each memory problem is detected, execution will stop and you can look at the program state with the debugger or simply continue execution. In general, do not use this with threading analysis because the analysis optimizations cannot be done when debugging, as mentioned above, making execution too slow.

A leak occurs when memory or other resources were not released during execution of the application, hence they are not reported until after the application exits. Therefore, leaks would not result in breakpoints during execution.

For debugging to be effective, execution needs to halt at the point a problem occurred. In order to do that, the optimizations employed in threading analysis must be disabled. The result is extremely slow execution of thread checking when done in conjunction with debugging. To make debugging feasible, the level of analysis and location where it is done must be limited. When a problem is selected and Debug This Problem is used, those limitations are applied automatically. If the debug options are used when starting a threading analysis, care must be taken in which level of analysis is used and where analysis begins. Data race detection causes the worst slow down.

Memory checking and thread checking perform dynamic analysis. In addition to the executable binaries and the input, the scheduling of the threads and the execution path also affect which issues the tools can find and report. Even when the executable binaries and the input are the same, the thread scheduling and the execution paths can be different from run to run.

The crash could be caused by a bug in your program or due to a bug in the tool. A latent bug in your program that did not appear when the program ran without the tool, could appear when running under the tool. The tool perturbs the program execution so the scheduling of the applications’ threads can be different with and without the tool. In addition, on the Windows* OS, the memory checking uses a fill pattern to mark uninitialized memory. If an application uses this uninitialized memory, a crash is possible. In this case, the last diagnostic produced by the memory checking would be an uninitialized read.

Since Intel® Inspector XE 2013 analysis tools execute in the program’s address space, a bug in the tool that can crash the tool will also crash the program.

If your program crashes under thread checking, the product prints a message telling you if the crash is due to a bug in your code or a bug in the product. If the crash is due to a bug in your code, the message also points you to the crash location. If the crash is due to a bug in the product, the message will ask you to contact customer support.

If your program crashes under memory checking, the last diagnostic generated may point to a problem in your program. If the problem is with the memory checking tools, the current product is not able to detect where the bug is. Please contact customer support to get help.

It depends on the scope of the potential errors. Thread checking analysis is dynamic, and only finds errors in the code that is executed. It does not detect errors in any code that is not executed. In the executed code, thread checking is able to find potential errors like data races, cross thread stack accesses and potential deadlocks. This is why thread checking sometimes reports errors in your program even if your program produces correct output.

No, thread checking in current product releases does not detect logical errors such as atomicity violations.

Yes. Both memory checking and threading checking perform analysis on available cores or hardware threads utilized by the target parallel program. In general, the analysis overhead scales nicely and is similar to the scaling factor seen by the target application.

Intel® Inspector XE 2013 is capable of detecting threading errors even on single-core machines. You don’t have to run thread checking on a multi-core machine as long as your program uses multiple threads. If your program creates threads explicitly using Windows* or POSIX* threading APIs, you don’t have issues with creating multiple threads on a single-processor and single-core machine. If your program uses Intel® Threading Building Blocks (Intel® TBB), OpenMP* pragmas, Intel® Cilk™ Plus, or another task or threading model that normally creates threads based on the number of available cores on the machine, you need to force the underlying threading model to create multiple threads.

Of course, you will get better performance if you have a multi-core machine.

You can reduce your data sets to make memory checking and thread checking run faster. As dynamic analysis tools, memory checking and thread checking detect errors on the code paths executed. As long as the execution paths are preserved, the size of data sets does not matter to analysis. Smaller data sets, however, reduce analysis workload and can boost analysis performance significantly.
Smaller data sets also reduce memory consumption by memory checking and thread checking tools, resulting in better performance. Furthermore, with thread checking, reduced memory consumption allows the tool to store more memory history information and to detect errors that can be missed when memory space is too tight and some memory history information has to be recycled in order for the analysis to continue.

To make thread checking run faster, you need to create your own analysis settings and have one or more of the following in your settings.

• Turn on only one type of checking at a time. For example, if you suspect you have a data race, turn on data race detection only but turn deadlock detection off, especially when there are lots of locks created in the program. If you suspect your program has a deadlock or lock hierarchy violation issue, try with only deadlock detection turned on.Turn off capturing the first access call stack using option -no-save-stack-on-first-access. Capturing the first access stack is expensive in terms of both time and space.
• Turn off capturing allocation call stacks using option -no-save-stack-on-allocation. Capturing the allocation call stack, especially in C++ programs with lots of objects allocated, is expensive in terms of both time and space.
• Reduce the number of levels of saved call stacks using the option -stack-depth. The deeper the call stack, the more memory space it takes and the more time to track the stack.
• Exclude modules you do not want to analyze with the option -exclude-module.
• Divide modules into several small sets. Analyze one set of modules at a time

Usually, a thread’s stack is private and should not be shared. In case a thread’s stack needs to be shared, the thread owning the stack and the thread accessing the stack need to coordinate on the accesses.

A cross thread stack access occurs when a thread touches a different thread’s stack when both threads are alive. This can happen when a thread publishes its stack address to other threads intentionally or accidentally, or when a thread’s stack overflows, especially when the thread’s stack is supplied by the user instead of the system. A thread touching a different thread’s stack can potentially corrupt the other thread’s stack or read garbage from it if the accesses by both threads are not well coordinated.

A cross thread stack access is a different kind of issue from data race. A data race on a thread’s stack is a cross thread stack access, but a cross thread stack access is not necessarily a data race. The access can be well synchronized and there is no data race but the access can still be a correctness issue. The accessing thread can still potentially corrupt the other thread’s stack or read garbage from it. Synchronization does not always guarantee that cross thread stack access is safe.

Intel® Inspector XE 2013 does not understand the logic of the program, so it cannot tell unsafe cross thread stack accesses from safe cross thread stack accesses. Therefore, it reports cross thread stack accesses whenever a thread access may potentially access a different thread’s stack. It is up to the user to determine if the access is intended and safe.

Thread checking may report cross thread access warnings in OpenMP* code or Intel® TBB programs even if the user does not have threads share stacks explicitly. This is because OpenMP* threads or Intel® TBB threads can share stack memory internally. However, as mentioned before, Intel® Inspector XE 2013 does not understand the logic of the program so it reports the cross thread stack access warnings.

Yes, you can specify the modules to be excluded in the GUI or command line for thread checking and memory checking.

However, this is not recommended for memory checking. Uninitialized memory or bad pointers can be passed into third-party libraries, and their use may not be detected if the third-party libraries were excluded. In cases like these, the problem is not in the third-party library.

Yes, you can create suppression rules for such problems. For subsequent analysis of that project, Intel® Inspector XE 2013 will still analyze those binaries, but problems in those modules will not appear in the result.
A new rule can be created from the GUI by clicking on the Suppress… item in the context menu on the Code Locations pane. You can select the Any… checkboxes to apply the same rule to a bigger set of problems.
Existing suppression rules are shown on the Intel® Inspector XE 2013 Project Properties > Suppressions tab.
As an alternative, you can exclude third-party modules from analysis completely. Excluding third-party modules from analysis also benefits performance. However, excluding third-party modules is not recommended for memory checking as described above.

To analyze a plug-in module, you need to run the application that loads and executes the plug-in module under Intel® Inspector XE 2013. You can use the module include or exclude options to have Intel® Inspector XE 2013 only analyze the plug-in module.

Without additional annotations, Intel® Inspector XE 2013 may report false positives when analyzing applications containing custom memory management API or custom synchronization primitives.

Intel® Inspector XE 2013 provides a set of APIs to allow you to annotate your source code to notify the analysis of your synchronization and memory management APIs.

No. Memory checking only detects errors that occur during the analysis run of your program.

Heap memory that has not been freed, and is not reachable, is reported as leaked at program termination. Reachability is determined by scanning global memory to find references to heap memory and then checking those memory regions, and so on, for further references.

In some circumstances, Intel® Inspector XE 2013 may report false positives or not report real problems. For example,
- Intel® Inspector XE 2013 may report false positives if the analyzed application uses custom memory management APIs and you do not annotate your source code to notify the analysis of your custom allocators.
- Intel® Inspector XE 2013 may report a false memory leak for an object that is located in global memory if its destructor does not execute until late in the shutdown process.
- Intel® Inspector XE 2013 uses some heuristics to eliminate false positives that may hide real issues.

First, use the Filters pane to focus on a particular module, source file or problem type. Then pick one problem from Problems pane and look at Code Locations pane. There you will see stacks for these code locations which can also help you to identify the problem. For problems related to a sequence of particular events (e.g. deadlocks) you might want to look at the Timeline pane which will show you distribution of this problem in time. Finally, try to double-click on interesting code locations to switch to the Sources window.

Every issue detected by the tool has at least one source stack associated with it. Some of these stacks may be more important than others, for example the two stacks of access associated with the threads that accessed the data in a data race are more important to resolving that problem than the stack of allocation (where the allocation occurred) of the object raced on. If two important stacks from two different issues of the same kind have the same “best” location, they are considered as observing the same location. Any two problems that share a location this way are considered to be part of the same problem set. Another way to think of this is that each problem set is a spanning tree of locations for one kind of issue.
The best location in a given stack is found using a heuristic that attempts to find the most basic stack location that is in the actual user code. Most of the time this works, but sometimes the best locations found may be in a user-written library or another low-level library that the user has source code for.

Yes, you can analyze a release optimized binary under Intel® Inspector XE 2013. However, there is no guarantee that Intel® Inspector XE 2013 will report the same issues as with a debug non-optimized binary and there is no guarantee that Intel® Inspector XE 2013 will show source lines or correct source lines. In addition, if the release build is not built with debug information, Intel® Inspector XE 2013 is unlikely to find as many problems as in a debug non-optimized build and in the case of memory checking, may report incorrect problems.

Yes, you can specify additional search directories on the Search tabs of the Intel Inspector XE 2013 Project Properties dialog box. For results created outside of the GUI, you need to create a project to configure these folders. If you are using the Microsoft Visual Studio* IDE, Intel® Inspector XE 2013 automatically retrieves additional search directories from your Visual Studio* project.

Though it is likely that Intel Inspector XE 2013 can find any memory or threading errors present in the code paths exercised in applications when run at the highest levels of analysis, there is no guarantee that Intel Inspector XE 2013 will find all memory and threading errors in your program.

No. Intel® Inspector XE 2013 memory checking and thread checking tools instrument and analyze your program binaries dynamically. You don’t need to recompile or rebuild your programs. We recommend use of debug binaries or release binaries with debug information, so that error reports can be attributed to source code locations.

Static analysis operates differently. See our static analysis page for details.

No, they are injected into your program’s address space at runtime.

No, the current Intel® Inspector XE 2013 does not support process attach or detach. In order to find multithreaded bugs in your process, Intel® Inspector XE 2013 has to monitor memory initialization events (memory checking) or synchronization events (thread checking) from the start of the program.

Of course, you can always stop Intel® Inspector XE 2013 manually at any time after analysis starts.

Memory checking and thread checking perform dynamic analysis. In addition to the executable binaries and the input, the scheduling of the threads and the execution path also affect which issues the tools can find and report. Even when the executable binaries and the input are the same, the thread scheduling and the execution paths can be different from run to run.

The crash could be caused by a bug in your program or due to a bug in the tool. A latent bug in your program that did not appear when the program ran without the tool, could appear when running under the tool. The tool perturbs the program execution so the scheduling of the applications’ threads can be different with and without the tool. In addition, on the Windows* OS, the memory checking uses a fill pattern to mark uninitialized memory. If an application uses this uninitialized memory, a crash is possible. In this case, the last diagnostic produced by the memory checking would be an uninitialized read.

Since Intel® Inspector XE 2013 analysis tools execute in the program’s address space, a bug in the tool that can crash the tool will also crash the program.

If your program crashes under thread checking, the product prints a message telling you if the crash is due to a bug in your code or a bug in the product. If the crash is due to a bug in your code, the message also points you to the crash location. If the crash is due to a bug in the product, the message will ask you to contact customer support.

If your program crashes under memory checking, the last diagnostic generated may point to a problem in your program. If the problem is with the memory checking tools, the current product is not able to detect where the bug is. Please contact customer support to get help.

Yes. Both memory checking and threading checking perform analysis on available cores or hardware threads utilized by the target parallel program. In general, the analysis overhead scales nicely and is similar to the scaling factor seen by the target application.

To analyze a plug-in module, you need to run the application that loads and executes the plug-in module under Intel® Inspector XE 2013. You can use the module include or exclude options to have Intel® Inspector XE 2013 only analyze the plug-in module.

First, use the Filters pane to focus on a particular module, source file or problem type. Then pick one problem from Problems pane and look at Code Locations pane. There you will see stacks for these code locations which can also help you to identify the problem. For problems related to a sequence of particular events (e.g. deadlocks) you might want to look at the Timeline pane which will show you distribution of this problem in time. Finally, try to double-click on interesting code locations to switch to the Sources window.

Every issue detected by the tool has at least one source stack associated with it. Some of these stacks may be more important than others, for example the two stacks of access associated with the threads that accessed the data in a data race are more important to resolving that problem than the stack of allocation (where the allocation occurred) of the object raced on. If two important stacks from two different issues of the same kind have the same “best” location, they are considered as observing the same location. Any two problems that share a location this way are considered to be part of the same problem set. Another way to think of this is that each problem set is a spanning tree of locations for one kind of issue.
The best location in a given stack is found using a heuristic that attempts to find the most basic stack location that is in the actual user code. Most of the time this works, but sometimes the best locations found may be in a user-written library or another low-level library that the user has source code for.

Yes, you can analyze a release optimized binary under Intel® Inspector XE 2013. However, there is no guarantee that Intel® Inspector XE 2013 will report the same issues as with a debug non-optimized binary and there is no guarantee that Intel® Inspector XE 2013 will show source lines or correct source lines. In addition, if the release build is not built with debug information, Intel® Inspector XE 2013 is unlikely to find as many problems as in a debug non-optimized build and in the case of memory checking, may report incorrect problems.

Yes, you can specify additional search directories on the Search tabs of the Intel Inspector XE 2013 Project Properties dialog box. For results created outside of the GUI, you need to create a project to configure these folders. If you are using the Microsoft Visual Studio* IDE, Intel® Inspector XE 2013 automatically retrieves additional search directories from your Visual Studio* project.

Though it is likely that Intel Inspector XE 2013 can find any memory or threading errors present in the code paths exercised in applications when run at the highest levels of analysis, there is no guarantee that Intel Inspector XE 2013 will find all memory and threading errors in your program.

No. Intel® Inspector XE 2013 memory checking and thread checking tools instrument and analyze your program binaries dynamically. You don’t need to recompile or rebuild your programs. We recommend use of debug binaries or release binaries with debug information, so that error reports can be attributed to source code locations.

Static analysis operates differently. See our static analysis page for details.

No, they are injected into your program’s address space at runtime.

No, the current Intel® Inspector XE 2013 does not support process attach or detach. In order to find multithreaded bugs in your process, Intel® Inspector XE 2013 has to monitor memory initialization events (memory checking) or synchronization events (thread checking) from the start of the program.

Of course, you can always stop Intel® Inspector XE 2013 manually at any time after analysis starts.

Memory checking and thread checking perform dynamic analysis. In addition to the executable binaries and the input, the scheduling of the threads and the execution path also affect which issues the tools can find and report. Even when the executable binaries and the input are the same, the thread scheduling and the execution paths can be different from run to run.

The crash could be caused by a bug in your program or due to a bug in the tool. A latent bug in your program that did not appear when the program ran without the tool, could appear when running under the tool. The tool perturbs the program execution so the scheduling of the applications’ threads can be different with and without the tool. In addition, on the Windows* OS, the memory checking uses a fill pattern to mark uninitialized memory. If an application uses this uninitialized memory, a crash is possible. In this case, the last diagnostic produced by the memory checking would be an uninitialized read.

Since Intel® Inspector XE 2013 analysis tools execute in the program’s address space, a bug in the tool that can crash the tool will also crash the program.

If your program crashes under thread checking, the product prints a message telling you if the crash is due to a bug in your code or a bug in the product. If the crash is due to a bug in your code, the message also points you to the crash location. If the crash is due to a bug in the product, the message will ask you to contact customer support.

If your program crashes under memory checking, the last diagnostic generated may point to a problem in your program. If the problem is with the memory checking tools, the current product is not able to detect where the bug is. Please contact customer support to get help.

Yes. Both memory checking and threading checking perform analysis on available cores or hardware threads utilized by the target parallel program. In general, the analysis overhead scales nicely and is similar to the scaling factor seen by the target application.

To analyze a plug-in module, you need to run the application that loads and executes the plug-in module under Intel® Inspector XE 2013. You can use the module include or exclude options to have Intel® Inspector XE 2013 only analyze the plug-in module.

No. Memory checking only detects errors that occur during the analysis run of your program.

Heap memory that has not been freed, and is not reachable, is reported as leaked at program termination. Reachability is determined by scanning global memory to find references to heap memory and then checking those memory regions, and so on, for further references.

In some circumstances, Intel® Inspector XE 2013 may report false positives or not report real problems. For example,
- Intel® Inspector XE 2013 may report false positives if the analyzed application uses custom memory management APIs and you do not annotate your source code to notify the analysis of your custom allocators.
- Intel® Inspector XE 2013 may report a false memory leak for an object that is located in global memory if its destructor does not execute until late in the shutdown process.
- Intel® Inspector XE 2013 uses some heuristics to eliminate false positives that may hide real issues.

First, use the Filters pane to focus on a particular module, source file or problem type. Then pick one problem from Problems pane and look at Code Locations pane. There you will see stacks for these code locations which can also help you to identify the problem. For problems related to a sequence of particular events (e.g. deadlocks) you might want to look at the Timeline pane which will show you distribution of this problem in time. Finally, try to double-click on interesting code locations to switch to the Sources window.

Every issue detected by the tool has at least one source stack associated with it. Some of these stacks may be more important than others, for example the two stacks of access associated with the threads that accessed the data in a data race are more important to resolving that problem than the stack of allocation (where the allocation occurred) of the object raced on. If two important stacks from two different issues of the same kind have the same “best” location, they are considered as observing the same location. Any two problems that share a location this way are considered to be part of the same problem set. Another way to think of this is that each problem set is a spanning tree of locations for one kind of issue.
The best location in a given stack is found using a heuristic that attempts to find the most basic stack location that is in the actual user code. Most of the time this works, but sometimes the best locations found may be in a user-written library or another low-level library that the user has source code for.

Yes, you can analyze a release optimized binary under Intel® Inspector XE 2013. However, there is no guarantee that Intel® Inspector XE 2013 will report the same issues as with a debug non-optimized binary and there is no guarantee that Intel® Inspector XE 2013 will show source lines or correct source lines. In addition, if the release build is not built with debug information, Intel® Inspector XE 2013 is unlikely to find as many problems as in a debug non-optimized build and in the case of memory checking, may report incorrect problems.

Yes, you can specify additional search directories on the Search tabs of the Intel Inspector XE 2013 Project Properties dialog box. For results created outside of the GUI, you need to create a project to configure these folders. If you are using the Microsoft Visual Studio* IDE, Intel® Inspector XE 2013 automatically retrieves additional search directories from your Visual Studio* project.

We recommend starting with static analysis to remove as many issues as possible at compilation time and, then move to memory checking to find and fix memory issues and finally, to thread checking to find and fix threading issues which are usually hard to find and fix. If the application has race conditions, it’s possible that a fix for an incorrect access found by memory checking could be accomplished by resolving the race condition, which can only be detected by thread checking. It might also be the case that when running under memory checking, because it can alter scheduling and timing, a latent deadlock in the code might occur. Fixing the deadlock issue (which may be reported by thread checking), would enable a full run of the application under memory checking.

No. Intel® Inspector XE 2013 memory checking and thread checking tools instrument and analyze your program binaries dynamically. You don’t need to recompile or rebuild your programs. We recommend use of debug binaries or release binaries with debug information, so that error reports can be attributed to source code locations.

Static analysis operates differently. See our static analysis page for details.

The Intel® Inspector XE 2013 interactive debugging feature allows you to use a standard debugger to investigate memory or threading problems found by Intel® Inspector XE 2013. It supports Microsoft* Visual Studio 2008 & Visual Studio 2010 debugger (Microsoft* Visual Studio 2012 support is coming) on Windows* OS and the Intel and GNU debuggers on Linux* OS.

It’s not that simple. Intel® Inspector XE 2013 does a binary runtime analysis of your application, which means there is analysis code executing part of the time, not just your application’s code. You can attach a debugger to this, but you would be looking at the analysis tool’s code much of the time and learn nothing about the problem the tool reported was in your code.

When debugging without memory or threading analysis, a code breakpoint will stop execution at the right location, but that location might be executed thousands of times before the conditions are right that resulted in the problem being reported. By combining debug with analysis, the tool does the work of determining when the problem conditions have occurred and stops at the right time as well as location.

On the Windows* OS when integrated with the Microsoft Visual Studio* IDE, the debug feature is accessible at two points: from the context-sensitive menu when viewing the list of problems in a result and when setting up a new analysis. On the Linux* OS when using the Intel® Inspector XE 2013 Standalone GUI, the debug feature is accessible in the same manner.

It is also available from the Linux* command line using the –appdebug or –debug-this options on the –collect action. Debugging during analysis is not available from the Intel® Inspector XE 2013 Standalone GUI or command line interface on the Windows* OS.

The most likely reason to use debug during an analysis is after you have examined the call stacks and code surrounding a particular memory or threading problem reported by Intel® Inspector XE 2013 and find you need more information to determine the cause, such as what the application’s variables hold at that point or what’s happening in other threads. Selecting Debug This Problem on the problem of interest returns you to that point of execution as quickly as possible since the analysis being done can be reduced in many cases.

Perhaps you want to check for errors in a particular section of an application that takes a long time to execute and the exclusion options do not provide the granularity level you’d like. You can reduce the time it takes to execute to the point within a module where you want error checking to begin by setting a code breakpoint and starting the run with the analysis off. When checking for threading errors, this technique is only efficient if the area chosen for analysis is quite small compared to the overall execution time when under analysis. Threading analysis optimization cannot be done during an analysis with debug enabled, leading to extremely slow execution. Running the complete analysis without debug may be faster than using the debug method to limit the area being analyzed. Checking for memory errors does not have this issue.

If you are looking for memory errors in an application for the first time and want the ability to debug in each problem as it is reported, then enabling the debugger with analysis from the start is what you want. As each memory problem is detected, execution will stop and you can look at the program state with the debugger or simply continue execution. In general, do not use this with threading analysis because the analysis optimizations cannot be done when debugging, as mentioned above, making execution too slow.

A leak occurs when memory or other resources were not released during execution of the application, hence they are not reported until after the application exits. Therefore, leaks would not result in breakpoints during execution.

For debugging to be effective, execution needs to halt at the point a problem occurred. In order to do that, the optimizations employed in threading analysis must be disabled. The result is extremely slow execution of thread checking when done in conjunction with debugging. To make debugging feasible, the level of analysis and location where it is done must be limited. When a problem is selected and Debug This Problem is used, those limitations are applied automatically. If the debug options are used when starting a threading analysis, care must be taken in which level of analysis is used and where analysis begins. Data race detection causes the worst slow down.

For debugging to be effective, execution needs to halt at the point a problem occurred. In order to do that, the optimizations employed in threading analysis must be disabled. The result is extremely slow execution of thread checking when done in conjunction with debugging. To make debugging feasible, the level of analysis and location where it is done must be limited. When a problem is selected and Debug This Problem is used, those limitations are applied automatically. If the debug options are used when starting a threading analysis, care must be taken in which level of analysis is used and where analysis begins. Data race detection causes the worst slow down.

You can reduce your data sets to make memory checking and thread checking run faster. As dynamic analysis tools, memory checking and thread checking detect errors on the code paths executed. As long as the execution paths are preserved, the size of data sets does not matter to analysis. Smaller data sets, however, reduce analysis workload and can boost analysis performance significantly.
Smaller data sets also reduce memory consumption by memory checking and thread checking tools, resulting in better performance. Furthermore, with thread checking, reduced memory consumption allows the tool to store more memory history information and to detect errors that can be missed when memory space is too tight and some memory history information has to be recycled in order for the analysis to continue.

To make thread checking run faster, you need to create your own analysis settings and have one or more of the following in your settings.

• Turn on only one type of checking at a time. For example, if you suspect you have a data race, turn on data race detection only but turn deadlock detection off, especially when there are lots of locks created in the program. If you suspect your program has a deadlock or lock hierarchy violation issue, try with only deadlock detection turned on.Turn off capturing the first access call stack using option -no-save-stack-on-first-access. Capturing the first access stack is expensive in terms of both time and space.
• Turn off capturing allocation call stacks using option -no-save-stack-on-allocation. Capturing the allocation call stack, especially in C++ programs with lots of objects allocated, is expensive in terms of both time and space.
• Reduce the number of levels of saved call stacks using the option -stack-depth. The deeper the call stack, the more memory space it takes and the more time to track the stack.
• Exclude modules you do not want to analyze with the option -exclude-module.
• Divide modules into several small sets. Analyze one set of modules at a time
  
  

Yes, you can specify the modules to be excluded in the GUI or command line for thread checking and memory checking.

However, this is not recommended for memory checking. Uninitialized memory or bad pointers can be passed into third-party libraries, and their use may not be detected if the third-party libraries were excluded. In cases like these, the problem is not in the third-party library.

Yes, you can create suppression rules for such problems. For subsequent analysis of that project, Intel® Inspector XE 2013 will still analyze those binaries, but problems in those modules will not appear in the result.
A new rule can be created from the GUI by clicking on the Suppress… item in the context menu on the Code Locations pane. You can select the Any… checkboxes to apply the same rule to a bigger set of problems.
Existing suppression rules are shown on the Intel® Inspector XE 2013 Project Properties > Suppressions tab.
As an alternative, you can exclude third-party modules from analysis completely. Excluding third-party modules from analysis also benefits performance. However, excluding third-party modules is not recommended for memory checking as described above.

Without additional annotations, Intel® Inspector XE 2013 may report false positives when analyzing applications containing custom memory management API or custom synchronization primitives.

Intel® Inspector XE 2013 provides a set of APIs to allow you to annotate your source code to notify the analysis of your synchronization and memory management APIs.