name of variables Involved in problem

name of variables Involved in problem


After running a "Locate Deadlocks and Data Races" in Inspector.
For the "Summary " or "Sources" tab; Is there a way to show the name of the variable(s) involved in the data "problem" in the "code location" window?
I see only function and source line and this makes it difficult for me.


9 posts / 0 new
Last post
For more complete information about compiler optimizations, see our Optimization Notice.


In the Code
locations area memory problems are referenced by file:line and function name.
To see the variable name you can expand the problem line it will be shown in
the code. So you can see the variable name from the code line. The variable
name is not highlighted, only the code line containing it.

tip is type of the problem. In the example below problem X4 is in the col
struct. Description says it is Read. In expression B=(int) (col.b*255);
only col is read, so this is the problem variable.

If you want
to see col directly highlighted inside the expression, Im afraid this is not
supported. Analysis allows to find instruction address, where problem occurred.
From the address it can find line in the sources, but not exact data object.

In my case I get many hints to the problem resembling the example below.
They are a mix of Read, write , allocation site and Synchronization allocation site and all of them are OpenMP directives.
What can I learn from this?
What variable have a Data Race in this case?


Is it possible to provide a sample of your application? I yes, you can make the thread private and attach it.



If you by sample mean the whole source code I do not believe I am allowed to post that, and its lots of code. But privately I believe I could post this subroutine if that would help you help me. :)

What do you think you need?

No, of course I don't need the whole project. Sampleis some little part of your code that could be run and analysed as separate project.The subroutine could be helpful if I can build a project based on it, and the data race can be found there - if it's located only inside the subroutine. I just mean, if you can create a little reproducer that have the reported problem, no matter what it actually does, it would help me much to understand how to proceed in this case.

I manage to reproduce it using a small program that is attached.

Use the Debug x64 configuration, the others I did not configure the settings for.
Below you see the settings I used for the Inspector run; as thorough as they gets.

When running the test I notice that the result varies from run to run. I run it four times to get the problem seen below.

My setup:
Core i7 860 (4 cores, 8 threads, 2.8 GHz)
win 7 x64
Intel Visual Fortran Compiler XE [Intel 64]...
Intel inspector XE 2011 update 3 (build 147581)

Can someone enlighten me about what I could learn from this kind of problems reports?

Best Regards,


Download no-variables3.zip2.6 KB

Hello Magnus,

Sorry for delay. Thanks for the sample I'm able to reproduce your behavior. This memory leak is found inside openMP code. There are memory allocations there.Thiscan be false-positive, it's unlikely that it is your code that introduces memory issue (in this case when lines 65 and 72 are highlighted). However it needs to be investigated if it is really false positives and why do they appear. I'll discuss it with our developers and come back to you with some updates.

Kirill Rogozhin

I've upgradedIntel Visual Fortran Composer XE and Intel Inspector XE to the last version (update 4 both). I can't reproduce the same issue now, however there are still a couple of Data Races that point to OpenMP procedures.
In the Data race shown on your screenshot Allocation site is in pbdx.dll. This is component of Intel Parallel Debugger. So the variable of interest is likely some debugger internal and the problem reported is not from your application code.

Login to leave a comment.