Support for Analyzers (Intel VTune™ Profiler, Intel Advisor, Intel Inspector)
This community is designed for sharing of public information. Please do not share Intel or third-party confidential information here.

Are these false positives?


I am running Inspector on a C++ application using OpenMP for parallel threading on Linux (Redhat 6).  In the "Locate Deadlocks and Data Races" tool, it reported a few correct data races, mostly on some counters that don't affect the output.  However, it also reported numerous data races under one ID in the Summary section that all appear to be in local stack variables allocated internally by the various threads.  They don't appear to be able to overlap in any way.  Is anyone aware of any issues with false positives similar to this?

Some of my Inspector settings were:

  • Stack Frame Depth: 24
  • Scope: Extremely thorough
  • Remove duplicates: checked
  • Use maximum resources: checked
  • Cross-thread stack access detection: Hide problems/Hide warnings Detect data races on stack accesses: Yes

Previously I had turned on cross-thread stack access detection, and got some puzzling positives there as well involving local stack accesses, that didn't appear to be caused by the code, as they were in local variables allocated on the stack inside each thread.

Also, when I ran the "Locate Memory Problems" tool, I got several warnings about Invalid memory access on the global char** environ variable, which also appear to be false positives.

Finally, we ran into a surprising difference between the Intel compiler and g++.  When we used a reinterpret_cast on a pointer and changed the dereferenced value, the original value pointed to did not change.  We were surprised to find that this is allowed by the C++ standard.  Anyway, we still have some other unexplained differences in execution and were wondering if you had or were aware of a list of potential portability issues converting from g++ to Intel's compiler.

Thank you for any insights on these issues!

0 Kudos
0 Replies