code crash under ifort v18+

[Ge__Guoqing]

   I recently tested my code under the new intel fortran compiler version 18 and above and found that the new compiler crashed my program. The problems is that v18+ ifort crashes pointer passings. Here is a demo code:

program test
  real(8),dimension(:,:) ,pointer::p1
  call sub1(p1)
end program test

subroutine sub1(ptr)
  real(8),pointer,intent(out) :: ptr(:,:)
  print *,'inside sub1'
end subroutine sub1

It ran good under ifort v14, 15,16,17, but got the following error under intel v18+:

          forrtl: severe (174): SIGSEGV, segmentation fault occurred

I don't understand what happened here. Hope some one can help. Thanks!

[Juergen_R_R]

Dear Guoqing, in fact the compiler should reject this code. sub1 is an external procedure with a pointer argument that needs an explicit interface. 

You could also make a module procedure out of sub1, then ifort2018 compiles and runs the code correctly. The following code also works correctly:

subroutine sub1(ptr)
  real(8),pointer,intent(out) :: ptr(:,:)
  print *,'inside sub1'
end subroutine sub1

program test
  interface sub1
     subroutine sub1 (ptr)
       real(8),pointer,intent(out) :: ptr(:,:)
     end subroutine sub1
  end interface sub1
  real(8),dimension(:,:) ,pointer::p1
  call sub1(p1)
end program test

That ifort (in all versions) accepts this code is a bug which you should report. 

[Ge__Guoqing]

Thanks, Juergen!  

You are right. I forgot to put an interface there. Sorry about that. But this is not my real problem.

I tried to mimic the bug (crash) I met in my real codes which is much complicated. But apparently I failed to do so.

The real problem I met under intel v18+ is the following codes: 

real(r_kind),dimension(:,:)  ,pointer::ges_ps
....
call gsi_bundlegetpointer(gsi_metguess_bundle(jj),'ps' ,ges_ps ,ips)

This gsi_bundlegetpointer is defined as :

   interface GSI_BundleGetPointer    ! get pointer to field(s) in bundle
          module procedure get1_     !   single-field
          module procedure get2_     !   many-field
          module procedure get31r4_  !   real*4 rank-1 explict pointer (real*4)
          module procedure get31r8_  !   real*8 rank-1 explict pointer (real*8)
          module procedure get32r4_  !   real*4 rank-2 explict pointer (real*8)
          module procedure get32r8_  !   real*8 rank-2 explict pointer (real*4)
          module procedure get33r4_  !   real*4 rank-3 explict pointer (real*4)
          module procedure get33r8_  !   real*8 rank-3 explict pointer (real*8)
   end interface

in my runtime, gsi_bundlegetpointer calls get32r8_(..).

subroutine get32r8_ ( Bundle, fldname, pntr, istatus )
    type(GSI_Bundle),intent(in) :: Bundle   ! the Bundle
    character(len=*),intent(in) :: fldname  ! name of field
    real(r_double),pointer,intent(out) :: pntr(:,:)  ! actual pointer to individual field
    integer(i_kind),       intent(out) :: istatus  ! status error code

Here is the bug I met under intel v18+:

if I explicitly nullify(get_ps) before gsi_bundlegetpointer(...), everything is okay;  but if ges_ps has already pointed to some memory, it will crash and does not enter get32r8_(...) at all.

The "traceback" debug option showed the following segmentation fault and the crash just happened at the line:

line 1869:  subroutine get32r8_ ( Bundle, fldname, pntr, istatus )

forrtl: severe (174): SIGSEGV, segmentation fault occurred
Image              PC                Routine            Line        Source
gsi.exe            00000000049700DD  Unknown               Unknown  Unknown
libpthread-2.19.s  00002AAAAB858870  Unknown               Unknown  Unknown
libiomp5.so        00002AAAAC353740  Unknown               Unknown  Unknown
libiomp5.so        00002AAAAC35602C  Unknown               Unknown  Unknown
gsi.exe            00000000049B2064  Unknown               Unknown  Unknown
gsi.exe            000000000237A3E6  gsi_bundlemod_mp_        1869  gsi_bundlemod.fpp

The same code ran good under compilers older than v18+.  

Hope you can further look at this. Thanks!

[Juergen_R_R]

This is too little information I fear to conclude something reasonable. I notice that libiomp5 is linked to your code, that means that you are using OMP in your code. Could that be a race condition that more than one subroutine call tries to access/output the same pointer? 

[Ge__Guoqing]

Juergen, thanks for your inputs!    Let me explain it a bit more although I knew it will not be enough to reach a solid conclusion.

ges_ps is a pointer which will point to an array (wrapped in a class) inside a subroutine (e.g sub1)

If ges_ps is null before passed into sub1, the program will run through; however, if ges_ps has already pointed to something before passed into sub1, the program crashes. 

I had also tried run the program using one core on one CPU, it still crashed.  I had not created a sample code for this problem but the whole program is too large to show here. Any thoughts, insights or how to track the problem will be greatly appreciated!

[FortranFan · Accepted solution]

@Ge, Guoquing,

See this thread at comp.lang.fortran re: INTENT(OUT) and POINTER attribute of dummy arguments and issue with Intel Fortran 18.0 and 18.0.1:

https://groups.google.com/d/msg/comp.lang.fortran/zWrmsDgJaLc/KK6E-VJdAQAJ

Your code might be affected by the same problem, but you will need to put together a complete reproducer to increase your chances of confirmation and for resolution.  Also, Intel now wants to submit incidents at their Online Service Center (OSC):

https://supporttickets.intel.com/?lang=en-US

where you can provide large code attachments as well as get confidentiality with your request.

[truecoder34]

Hi @FortranFan , As I understood correctly you have worked with gsi code. I have an issue in hybrid MPIxOMP version of this code. Could you please share you experience about this code? 

[FortranFan]

@truecoder34 ,

Sorry I've no such experience.

[Ge__Guoqing]

Thanks a lot , FortranFan!  The thread you recommended is very helpful and it inspired me find a workout solution to eliminate the crash in my project. Thanks again!

[truecoder34]

Hi @Ge__Guoqing , As I understood correctly you have worked with gsi code. I have an issue in hybrid MPIxOMP version of this code. Could you please share you experience about this code?