inquire in a parallel OpenMP region crashes

[John_Young]

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

[jimdempseyatthecove]

Line 35 of your program should read:

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

See if this fixes your problem.

Jim Dempsey

[John_Young]

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]

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]

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]

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]

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]

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]

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 · Accepted solution]

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]

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]

Ron,

Thanks for looking at this.

John

[Ron_Green]

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

[Ron_Green]

@John_Young  and @jimdempseyatthecove  this bug was fixed in 2023.0.  The INQUIRE with PENDING, yes, also same bug in a similar code path fixed.