Troubleshooting

The sum of the several summands in the table view is not equal to the overall time shown for the parent of the items.

Cause

The values in the data columns are rounded. For items that are sums of several other items, such as a function with several stacks, the rounded sums may differ slightly from the sum of rounded summands.

For example:

The rounded values in the grid do not sum up exactly as (0.123 + 0.123) != 0.247.

The Call Stack pane shows more stacks than the call tree in the Bottom-up pane.

Cause

There are several stacks going to the same function, but to different code lines.

The call tree in the Bottom-up pane aggregates these stacks in one line but the Call Stack pane shows each as a separate stack. For more details, see the Pane: Bottom-up topic.

The information displayed in the Call Stack pane is incorrect.

Cause

The debug information may be incomplete.

Solution

Re-compile the target with full debug information. For instructions on how to enable this option, see the Using Debug Information topic.

The stack in the Top-down Tree pane is incorrect.

Cause

The target was built with an optimization level that removed stack information from the binary.

Solution

Decrease the optimization level of your project and rebuild the target. Then profile with the VTune Amplifier.

The Call Stack Mode option on the filter bar is set to Only user functions but system functions still appear in the result windows.

Cause

If there is a system function that has no user function calling it, the system function appears and its time is shown in the analysis result windows.

By default, the Allow multiple runs option, located on the Analysis Target tab, is disabled. As a result, the VTune Amplifier uses event multiplexing and runs the data collection only once. This approach lowers the precision of the collected data. So, the VTune Amplifier calculates the number of collected events using the formula: Events= Sample After Value (SAV) * Samples. But when the event multiplexing is enabled, this formula is modified as follows: Events= Sample After Value * Samples * Event Group Count, where the Event Group Count is the number of incompatible groups of events used during the collection. The Event Group Count multiplier is introduced based on the heuristics approach to fill the gaps when the VTune Amplifier collected events for one event group only.

For example, you have three groups of events: A, B and C, where event A1 is in group A. During the application run, the VTune Amplifier spends equal time on collecting each group of events. While group A is analyzed, event A1 has 10 samples with SAV of 10.000 and your application generates no A1 samples at all for the rest of the time. In this case, the accurate result is 100.000 events (10.000 * 10). But the VTune Amplifier provides the resultant number of events as 100.000 * 3 (A, B and C groups) = 300.000.

Solution

Select the Allow multiple runs option to disable event multiplexing and run a separate data collection for each event group. This mechanism provides more precise data on collected events.

VTune Amplifier displays [Skipped frame(s)] in the Bottom-up/Top-down Tree panes.

Cause

VTune Amplifier did not unwind the stack to reduce data collection overhead, and failed to resolve the stack heuristically.

Solution

You may collect deeper stacks by creating a custom event-based sampling analysis and increasing the Stack size option value in bytes (-stack-size option in CLI), though beware that this also increases the collection overhead.

VTune Amplifier displays [Guessed frame(s)] in the Bottom-up/Top-down Tree panes.

Cause

VTune Amplifier did not unwind the stack to reduce data collection overhead, but resolved the stack heuristically.

[Guessed frame] is considered to be a system function. If the Call Stack Mode filter bar option is set to User/system functions, the VTune Amplifier displays [Guessed frame(s)].

Solution

To avoid displaying [Guessed frame(s)], set the Call Stack Mode filter bar option to Only user functions.

CPU Sleep States viewpoint displays an {Unknown Timer} with a blank process name and {Unknown} PID/TID.

Cause

The kernel configuration prevents the VTune Amplifier for Systems from collecting the required data: it cannot identify the PID/TID/module or process name for the timer.

Solution

You may set the CONFIG_TIMER_STAT =Y in the boot configuration file and recompile the kernel.

The same functions are compared as different instances in the Bottom-up/Top-down Tree panes.

Cause

You are using the Function Stack grouping for the recompiled binary. The Function Stack grouping uses function start addresses and is based on function instances.

Solution

Switch to the Source Function Stack grouping level to ignore start addresses and display the data by source file objects.

Hardware event-based sampling analysis results may be incorrect if nmi_watchdog interrupt capability is enabled.

Cause

If the nmi_watchdog interrupt capability is enabled, event-based analysis results may be incorrect. For example, when using a pause-resume scenario for event-based analysis on 64-bit Red Hat* Enterprise Linux* 6.1 with this feature enabled, no data will be collected when the collection is resumed.

Solution

Before running an event-based analysis, ensure that the nmi_watchdog interrupt capability, if available, is disabled.

To permanently disable the nmi_watchdog interrupt:

1. Under the root account, edit /boot/grub/grub.conf by adding the nmi_watchdog=0 parameter to the kernel line so that it looks like: /boot/vmlinuz-2.6.32-131.0.15.el6.x86_64 ro root=/dev/sda8 panic=60 nmi_watchdog=0 2.

2. Reboot the system.

3. After rebooting, enter the following command to verify whether nmi_watchdog is disabled: grep NMI /proc/interrupts. If you see zeroes, nmi_watchdog is successfully disabled.

To temporarily disable the nmi_watchdog interrupt, enter:

echo 0 > /proc/sys/kernel/nmi_watchdog

Information collected via ITT API is not available when attaching to a process.

Cause

If you use ITT API in your source code to collect statistics data, like Frame Analysis or JIT-profiling, attaching to a process does not provide expected results.

Solution

To enable an analysis, specify an application to launch as an analysis target instead of attaching to a process.

Stack size provided to sigaltstack is too small. Please increase the stack size to 64K minimum.

Cause

When setting up SIGPROF signal handler, the VTune Amplifier attempts to configure the signals to use the alternative stack size using sigaltstack() API to make sure that its signal handler does not depend on the stack size of the profiled application. If the application uses alternative signal stack itself, the VTune Amplifier requires that the alternative stack size is 64K at a minimum. This may be not the case if the application uses SIGSTKSZ constant for the alternative stack size (which is 8192 bytes). In this case, the data collection may terminate with the error message.

Solution

Configure the VTune Amplifier not to set up the alternative stack and use the stack provided by th application. To do this, pass the following command line options to the tool:

> amplxe-cl -run-pass-thru=--no-altstack

Or, set up the environment variable AMPLXE_RUNTOOL_OPTIONS=--no-alstack.

Application sets its own handler for signal <conflicting_signal> that is used for internal needs of the tool. Collection cannot continue.

Cause

User-mode sampling and tracing collector cannot profile applications that set up the signal handler for a signal used by the VTune Amplifier.

Solution

When collecting data with amplxe-cl, add the --run-pass-thru=--profiling-signal <not_used_signal> command line option, where <not_used_signal> is a signal that should not be used by your application to analyze; you need to select the signal from SIGRTMIN..SIGRTMAX.

Alternatively, you may set the environment variable AMPLXE_RUNTOOL_OPTIONS=--profiling-signal <not_used_signal>. You may do this, either from your terminal window before running the VTune Amplifier GUI or from the User-defined Environment Variables dialog box accessible from the VTune Amplifier Analysis Target tab.

Required key not available

Cause

For hardware event-based sampling analysis and Intel Energy Profiler analysis with VTune Amplifier for Systems, an Android system requires signed drivers. Every time the Android kernel is built, a random private/public key is generated. Drivers must be signed with the random private key to be loaded. The drivers must be signed with the same key and be compiled against the same kernel headers/sources as what is installed on the Android target system.

Solution

Make sure you use the same signing key that was produced at the time and on the system where your kernel was built for your target.

Problem accessing the sampling driver. The driver may need to be (re)started...

Cause:

VTune Amplifier cannot access the hardware event-based sampling (EBS) driver required to run a hardware event-based sampling analysis type. This problem happens if the sampling driver was not loaded or you do not have correct permissions.

Solution:

Make sure the sampling drivers are loaded:

> lsmod | grep sep3_1

> lsmod | grep pax

If the drivers are already loaded, make sure you are a member of the vtune user group. You can check the /etc/group file or contact your system administrator to find out if you are a member of this group. For more details, see the Building and Managing the Sampling Driver topic.