Intel® Fortran Compiler
Build applications that can scale for the future with optimized code designed for Intel® Xeon® and compatible processors.
Announcements
This community is designed for sharing of public information. Please do not share Intel or third-party confidential information here.
27239 Discussions

inquire in a parallel OpenMP region crashes

John_Young
New Contributor I
284 Views

Hi,


We've noticed an hard crash when calling the inquire function many times in a OpenMP parallel for loop.  I've attached a test case with screen output that illustrates the problem. It is more severe as you increase the number of threads and/or increase the loop iteration count. With 8 or more threads, the code almost always crashes. With fewer than 8 threads the code may or may not crash.

Wrapping the inquire statement in an OpenMP critical section prevents the crash entirely. However, we do not understand what the underlying issue is. Why can you not call inquire repeatedly inside an OpenMP region without the critical section?

Thanks,

John

0 Kudos
1 Solution
Ron_Green
Moderator
204 Views

It is unique to WIndows, and I do see the crash even with the latest 2022 compiler.  Not surprising that linux works and windows does not, different code paths to use different OS thread management api.   So probably some race condition on Windows.  I'll get the Runtime library people to look at the source for INQUIRE and see if we can find the problem.

View solution in original post

12 Replies
jimdempseyatthecove
Black Belt
274 Views

Line 35 of your program should read:

    !$OMP PARALLEL PRIVATE(tid, fname, i)

 

See if this fixes your problem.

 

Jim Dempsey

John_Young
New Contributor I
270 Views

Jim,

 

That is a good catch and it was sloppy coding on my part.  I've attached the updated test case. However, that is not the issue. The code still crashes.

 

John

jimdempseyatthecove
Black Belt
247 Views

What happens when you remove "reduction(+:s)" from the !$omp do?

.OR.

Inside that do loop, insert

 

   s = s+1

 

What may be happening is s (as written) was not used neither inside nor outside the loop. As such, the compiler may have optimized it out. However, the reduction clause is (I assume) unaware that s no longer exists. As such, the address resolved to either 0 or "junk", and this in turn exhibited a Segfault during the "reduction".

 

Edit: Oh, and after the !$omp do use s in a manner such that it does not get optimized out (though I think it won't). i.e

  ...

!$omp end do

print *,s

!$omp end parallel

print *,s

...

 

Jim Dempsey

 

jimdempseyatthecove
Black Belt
244 Views

As an odd observation, consider what happens with:

  ...

 !$OMP DO SCHEDULE(STATIC) reduction(+:s)
do i = 1,100000
   call test(fname)
end do
!$omp end do nowait

print *,s

s = s+1

!$omp end parallel

print *,s

...

What do you think will/should print out?

 

Jim Dempsey

John_Young
New Contributor I
239 Views

Jim,

 

That's a good observation, but the reduction is not the issue.  I originally had the 'inquire' directly in the do loop and the optimizer kept optimizing the loop away.  So, I had an s=s+1 in the loop with reduction and a final print statement to force the loop to run.  Later, I moved the inquire into a subroutine and no longer needed the s=s+1/print to prevent the loop from being optimized away. When I removed it, I forgot to remove the reduction.

I've attached an updated test without the reduction. Again, this is not the issue and the code still crashes.

 

John

jimdempseyatthecove
Black Belt
231 Views

Then (assuming optimizing out of code not using results of variable), what happens if after the inquire, you add:

 

if(isOpened) print *,isOpened ! should not be true in this test program.

 

Regardless as to if this fixes the issue, the program should not result in a crash.

 

If this does not fix the issue, then this would be indicative that INQUIRE (as used) is not thread-safe.

 

Jim Dempsey

John_Young
New Contributor I
223 Views

Adding

     if(isOpened) print *,isOpened

does not lead to anything additional being printed to the screen. The program still crashes when using a sufficient number of threads.

 

 

Ron_Green
Moderator
211 Views

I tested v2 with Linux 2021.3 compiler.  8 threads, 64 threads, 16 threads, 1 thread - no crashes.  

I'll pull out my PC laptop for testing on Windows.  However, I only have the latest 2022 compiler installed on it.

Ron_Green
Moderator
205 Views

It is unique to WIndows, and I do see the crash even with the latest 2022 compiler.  Not surprising that linux works and windows does not, different code paths to use different OS thread management api.   So probably some race condition on Windows.  I'll get the Runtime library people to look at the source for INQUIRE and see if we can find the problem.

jimdempseyatthecove
Black Belt
199 Views

Ron, when you forward the information, please inform them that there may be a related issue with INQUIRE with PENDING. I had a similar issue using w_comp_lib_2020.0.166. It may be some common code, or it may be a copy'n'paste issue in each code path.

Sorry, I do not have a reproducer handy. When (if) they find the problem with INQUIRE with OPENED, it should be easy enough to locate same mistake elsewhere within INQUIRE.

 

Jim Dempsey

 

John_Young
New Contributor I
186 Views

Ron,

 

Thanks for looking at this.

 

John

Ron_Green
Moderator
170 Views

I opened a bug report CMPLRLIBS-33965. Jim, I included your request for investigation to the bug report.


Reply