- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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!
Link Copied
- Subscribe to RSS Feed
- Mark Topic as New
- Mark Topic as Read
- Float this Topic for Current User
- Bookmark
- Subscribe
- Printer Friendly Page