Crash with allocatable structures in OpenMP loop

[Sebastien__Bardeau]

Hi,

running the attached OpenMP code with ifort 18.0.3 results in a segmentation fault:

$ ifort -fopenmp gtemplate.f90 -o gtemplate && ./gtemplate
forrtl: severe (174): SIGSEGV, segmentation fault occurred
forrtl: severe (174): SIGSEGV, segmentation fault occurred

Does anyone confirm the crash? And what could be the issue? Something illegal with the private-per-thread structure? Thanks,

Sebastien

[Juergen_R_R]

Salut Sebastien, I am not an expert on OMP. But this looks not very good. I can confirm the issue with both ifort and NAG. I assume that the problem is that you have an OMP-parallel loop accessing the global object hbeam and its component. This generates a race condition, most likely if more than one thread tests positively for hbeam%teles being allocated and trying to deallocate it in parallel. 

[Sebastien__Bardeau]

The structure "hbeam" is declared FIRSTPRIVATE, which means that 1) each thread should have its own copy and 2) each copy should be identical (i.e. values initialized) to the original structure. From this point I believe I should be able to deallocate each copy. As I do not reproduce the crash with gfortran, I thought it was an ifort issue. But if you believe that's an OpenMP problem, I can ask for help on comp.lang.fortran.

[Sebastien__Bardeau]

Hi, I am facing again a crash when using allocatable arrays in structures, when the structures are set as PRIVATE in a parallel OpenMP region. I could not test the latest ifort release. Can anyone check if the example I attached in my first post still crashes? Thanks.

[jimdempseyatthecove]

I seem to recall an issue with earlier versions of IVF with use of private and firstprivate of user defined types containing allocatables (as well as the private entity being allocatable as well). Do you need a work around?

Jim Dempsey

[jimdempseyatthecove]

Untested code that ought to work.

module myclean_arrays
  !
  type :: telesco
    character(len=12) :: ctele
  end type telesco
  !
  type :: gildas
    type(telesco), allocatable :: teles(:)
  end type gildas
  !
  type (gildas) :: hbeam
  !
end module myclean_arrays
!
program gtemplate
  use myclean_arrays
  ! Local
  integer(kind=4) :: jfield
  !
  ! At this point hbeam%teles is not allocated
  !$OMP PARALLEL DEFAULT(none) &
  !$OMP   & FIRSTPRIVATE(hbeam) &
  !$OMP   & PRIVATE(jfield)
  ! at this point the teles of the private copy of hbeam is not allocated
  ! allocate it
  allocate(hbeam%teles(1))
  ! initialize it
  hbeam%teles(1)%ctele = 'NOEMA'
  ! do some meaningless valid code that exhibits the issue
  !$OMP DO
  !
  do jfield=1,1000
    if (allocated(hbeam%teles)) deallocate(hbeam%teles)
  enddo
  !
  !$OMP END DO
  ! in event that you have more threads than 1000
  if (allocated(hbeam%teles)) deallocate(hbeam%teles)
  !$OMP END PARALLEL
  !
end program gtemplate

The prior bug had issues with the (first)private having allocatables. The old work around was to enter the parallel region with the unallocated components (thus firstprivating an unallocated array descriptor) then perform the allocations within the parallel region.

Jim Dempsey

[Barbara_P_Intel]

This is a problem with the compiler.  I filed a bug report with the developers on your behalf.

Jim's idea is a good workaround.

[Sebastien__Bardeau]

Dear Barbara and Jim,

as far as I understand, the crash is about implicit allocation of the allocatable component when the structure is to be duplicated (FIRSTPRIVATE) to all threads. Knowing this, yes, Jim's workaround is a solution. I can imagine others, as my real use case is more complicated than my example. I need to review my code.

Barbara, it would nice to know when (which revision) the fix for this issue is released.

Thank you for your support.

[Barbara_P_Intel]

I have a note to watch for the fix and let you know.

[Barbara_P_Intel]

I have an update on this issue with allocating outside a parallel region and deallocating what was allocated outside the parallel region inside a parallel region. 

The developer has several workarounds:

(1)  both allocate and deallocate outside the parallel region

(2)  allocate and deallocate inside the parallel region

(3)  Use SHARED clause

       program test
          integer, allocatable :: AAA(:)
          allocate(AAA(100))

          !$OMP PARALLEL SHARED(AAA)
          ...
          !$OMP MASTER
          if (allocated(AAA)) deallocate(AAA)
          !$OMP END MASTER
          !$OMP END PARALLEL
        end program test

The plan is to fix this issue in a future release of the compiler.  No promises, though, when that will be.