Community
cancel
Showing results for 
Search instead for 
Did you mean: 
Ge__Guoqing
Beginner
150 Views

code crash under ifort v18+

Jump to solution

 

   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!

0 Kudos

Accepted Solutions
FortranFan
Honored Contributor I
150 Views

@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.

View solution in original post

9 Replies
Juergen_R_R
Valued Contributor I
150 Views

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
Beginner
150 Views

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
Valued Contributor I
150 Views

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
Beginner
150 Views

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
Honored Contributor I
151 Views

@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.

View solution in original post

Ge__Guoqing
Beginner
150 Views

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
Employee
81 Views

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? 

truecoder34
Employee
75 Views

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
Honored Contributor I
49 Views

@truecoder34 ,

Sorry I've no such experience.