wierd OpenMP Problems

[mklvml]

Hi.

I produced the following minimal example of my problem. If I run it I get an access violation.
My problem is, that if I change ANYTHING in the code, the error disappeares. But WHY!!!!!!!?!?!?!?!
Please help me. I am searching for hours!
(Even If I remove one of the two statements after "stop", or the print*,"" the error disappeares.
Or if I change the compiler options (other opimitzation level or debugging) it goes away!!!
Or if the subroutine and function are in the "Prorgam.f90" file!)


Intel Fortran 11.1.060



Compiler Options:

/nologo /Os /heap-arrays0 /module:"x64\\Release\\\\" /object:"x64\\Release\\\\" /libs:static /threads /c /Qopenmp



Source:

______________________________________________
File1.f90

subroutine Sub()
implicit none

integer,dimension(:,:),allocatable::A
integer,dimension(:),allocatable::P
real,dimension(:),allocatable::C,B
real,dimension(:),allocatable::unused1,unused2,unused3,unused4

real::Func

print*,""

allocate(C(1))
allocate(B(1))
allocate(A(1,1))


!$OMP PARALLEL SHARED(A,B,C) &
!$OMP DEFAULT(NONE) &
!$OMP PRIVATE(P) NUM_THREADS(1)

allocate(P(1))

B(1) = Func(A(:,1) )

!$OMP END PARALLEL

end subroutine


real function Func(arg)
implicit none
integer, intent(in),dimension(1) :: arg
Func = 0
end function


______________________________________________
Program.f90

program test
implicit none

real,dimension(:,:,:),allocatable::A

call Sub( )

stop

print*,allocated(A)
print*,ubound(A)

end program

[Wendy_Doerner__Intel]

I have compiled and run this test case with Microsoft Visual Studio 2010 and 12.0.2.154 (12.0 Update 2) and VS 2008 and 11.1.060 compilers with out an access violation. I used the same swtiches you did and ran the application from inside Visual Studio. I have zipped up my VS 2008 solution if you want to try it to see if you still get an access violation or see any other differences.

Thanks,

------

Wendy

Attaching or including files in a post

[mklvml]

THank You!
I compiled it an there was no access violation.

BUT: It turned out (i cant believe it myself), that the binaries produce errors or work depending, where on my harddrive I put them. For example: If I use the (working) binary from your Project into the folder of my other solutoin it stops working and vice versa. If i move it to c:\ it works, if I move it to e:\ it stops working!

What do you think about that???

[Wendy_Doerner__Intel]

I am puzzled. Access violations typically happen when there is a lack of permissions on a directory, when when you perhaps have an application compiled for one architecture (i.e. Intel 64) and then try to run on another (IA32) or when there is a user coding error. Don't think any of these apply here.

Perhaps next steps would be to start removing options from your command line and see if the access violation goes away. Also youcould add the /check switch to your command line which finds some kinds of user coding errors at runtime.

Also can you tell me a little more about your system (processor type, OS) and what OpenMP environment variables are set (you can do a SET in a command prompt).

I am also asking one of our OpenMP specialists to take a look at this for ideas and he may also post.

------

Wendy

Attaching or including files in a post

[pbkenned1]

Considering this snippet:

!$OMP PARALLEL SHARED(A,B,C) &

!$OMP DEFAULT(NONE) &

!$OMP PRIVATE(P) NUM_THREADS(1)

allocate(P(1))

B(1) = Func(A(:,1) )

!$OMP END PARALLEL

If you were not using just one thread, then there's a data race on updating B(1), which is shared. I removed the NUM_THREADS(1) and confirmed that with an Inspector XE threading analysis. Putting that inside an !$OMP CRITICAL removes the race.

But that doesn't explain the access violation you're seeing, since data races normally just produce invalid/indeterminate results.

However, there may be some issue with the allocate(P(1)) statement. When I ran an Inspector XE deep memory analysis, it reported an invalid memory access from dgbheap.c, which is a Microsoft* routine. Unfortunately, I can't tell if this is a Microsoft issue, Intel Fortran issue, or a combination issue.

I'll run a similar analysis on Linux and update this thread with the results.

Patrick Kennedy
Intel Developer Support

[jimdempseyatthecove]

Inside your parallel region you have a private array P that is allocated but not deallocated. Prior to !$OMP END PARALLEL try inserting a deallocate(P). Although C, B and A are also arrays, allocated in Sub, they are allocated outside the scope of the parallel region. While the auto deallocation of C, B and A would be of no problem, your expectation of P being auto-deallocated is incorrect.

Now as to what the OpenMP spec says to this, I am not sure. The test is simple enough to perform.

Jim Dempsey

[mklvml]

Thanks for the advice. Still got the error!

[jimdempseyatthecove]

Then try declaring the interface for Func in Sub

[fortran]subroutine Sub()        
  implicit none 
  ...
! was   real::Func
! change to
     
  interface
  real function Func(arg)
    implicit none
    integer, intent(in),dimension(1) :: arg
  end function 
  end interface
  ...
end subroutine Sub
     
[/fortran]

Jim Dempsey