- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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!
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
@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.
Link Copied
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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+.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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?
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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!
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
@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.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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?
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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!
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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?
- Subscribe to RSS Feed
- Mark Topic as New
- Mark Topic as Read
- Float this Topic for Current User
- Bookmark
- Subscribe
- Printer Friendly Page