Community
cancel
Showing results for 
Search instead for 
Did you mean: 
jansson
Beginner
48 Views

name of variables Involved in problem

Hi,

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.

Regards,
Magnus

0 Kudos
8 Replies
Kirill_R_Intel
Employee
48 Views

Hello Magnus,

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.

Indirect 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.

jansson
Beginner
48 Views

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?
Regards,
Magnus


Kirill_R_Intel
Employee
48 Views

Magnus,

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

Regards,
Kirill
jansson
Beginner
48 Views

Kirill,

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?
Regards,
Magnus
Kirill_R_Intel
Employee
48 Views

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.
jansson
Beginner
48 Views

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 12.0.3.175 [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,
Magnus

Kirill_R_Intel
Employee
48 Views

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.

Regards,
Kirill Rogozhin
Kirill_R_Intel
Employee
48 Views

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.
Reply