This topic lists some situations in which either the experiments have erroneous data or the Performance Analyzer displays data that seems incorrect.
If you attach dbx to a process that is using the hardware counter library, libcpc.so, without preloading the collector library, then enable the collection of hardware counter data, the experiment is corrupted. The use of the hardware counter library by the collector conflicts with the use by the program. If libcpc.so, is loaded after dbx is attached to the process and hardware counter overflow profiling is enabled, the experiment can be correctly recorded if the references to the functions in libcpc.so are resolved using a general search. In this case, the wrapper routines from the collector library are used to resolve the references, and the use of the hardware counter functions by the program is disabled.
Incorrect values for Wait CPU time are sometimes recorded in the sample packets and the global statistics. These values appear in the Statistics tab of the Performance Analyzer and affect the display of samples in the Timeline tab. This problem has not yet been resolved.
If you collect clock-based profiling data on a program when there is a load on the system, the User CPU time can be undercounted by up to 20%. The missing User CPU time shows up either as System CPU time or as Wait CPU time. The workaround is to collect data when the system is not loaded, if at all possible.
If you dynamically compile a function and provide information on the function to the Collector using the collector API, you can see annotated source code. However, you see only non-zero metrics for the selected function. All other functions in the source file show zero metrics. This does not mean that there were no metrics recorded for these source lines, only that the values are not available.
The time values displayed in the Statistics tab include contributions other than the ones that are included in the timing metric values for <Total>. These contributions come from the following sources:
Inclusive times that are reported on source lines for OpenMP parallelization directives are erroneously double-counted. The times reported on the source lines for the code that is outlined into body functions is correct. Time reported for some functions is also incorrect as a consequence.