Community
cancel
Showing results for 
Search instead for 
Did you mean: 
Highlighted
Beginner
34 Views

"forrtl: severe (174): SIGSEGV, segmentation fault occurred" after adding or removing write-type commands

Hi, 

I'm compiling an ice sheet model using IFORT. If I add or remove some very simple write-type code, I have the following error message 

forrtl: severe (174): SIGSEGV, segmentation fault occurred
Image              PC                Routine            Line        Source             
libintlc.so.5      00007F4D9B0E3961  Unknown               Unknown  Unknown
libintlc.so.5      00007F4D9B0E20B7  Unknown               Unknown  Unknown
libifcore.so.5     00007F4D9CAA41D2  Unknown               Unknown  Unknown
libifcore.so.5     00007F4D9CAA4026  Unknown               Unknown  Unknown
libifcore.so.5     00007F4D9CA10E0C  Unknown               Unknown  Unknown
libifcore.so.5     00007F4D9CA21BF8  Unknown               Unknown  Unknown
libpthread.so.0    00007F4D9AEC9340  Unknown               Unknown  Unknown
sheetshelf.exe     000000000AA54D90  Unknown               Unknown  Unknown

Here is an example  of a write command I removed 

#       do iu = ioterm, iuout1d, iuout1d-ioterm
#       write (iu,'(a,i3,2(a,f10.4))')
#     *    'itera=',itera, '  delmaxa=',delmaxa,'  delcrita=',delcrita
#       enddo

and here is an example of a write command I added 

#       write(*,*)'crhu-schoof',crhu(iau,j),iau,j

I checked many times that there are no errors re the variables I want to be written, so I really can't understand why this happens. Do you have any hint how to understand more of this error? 

 

Thank you,

Michele

 

0 Kudos
3 Replies
Highlighted
Black Belt
34 Views

I/O statements (and, in

I/O statements (and, in general, other added statements) often pose obstacles to optimization. A side effect is that their addition alters the memory access patterns of the program. If the access errors occur only when WRITE statements are removed, I'd suspect that lowering the optimization level for that particular source file may cause the bug to disappear (or become hidden). If adding WRITE statements is observed to cause access errors, I'd suspect bugs in the program, which may be hunted down with subscript and argument checking, etc.  Sometimes, such bugs can be very difficult to isolate and remove.

Can you post a complete test source-code set?

0 Kudos
Highlighted
Beginner
34 Views

Hi mecej4, 

Hi mecej4, 

thank you for the reply. 

To add/remove WRITE statements either causes errors/"fix" errors. Right now my program is running with no errors at all; all I've done is to insert the following

#     if(abs(f(i)).gt.1.E+14.or.abs(g(i)).gt.1.E+14) then

#            write(*,*)'f',i-1,f(i-1),i,f(i)

#            write(*,*)'g',i-1,g(i-1),i,g(i)

#     end if

Trying to do other changes I also had errors like floating overflow (72) or divide by zero. I thought initially that such errors could have been caused by convergence issues while computing ice thickness and/or velocities. Is it possible that also those errors are memory-related? 

About your request, if you mean source-code analysis, are there online or offline free programs to do that? I'm a beginner, so I'm not even sure how to do it... 

 

Cheers,

Michele

 

0 Kudos
Highlighted
34 Views

SIGSEGV errors are addressing

SIGSEGV errors are addressing errors. It is likely that:

a) Something corrupted reference on the call stack (e.g. addressing a stack placed array out of bounds)
b) A stack argument was not passed (missing argument on call), resulting in a junk reference.
c) Something corrupted an array descriptor (e.g. addressing a stack .OR. module placed array out of bounds)

Note, divide by zero can also be caused by any of the above causes (by having a value unexpectedly zeroed).

Note 2, the "something" mentioned can also include corruption caused by improperly calling a non-Fortran function (using the wrong calling convention).

Jim Dempsey

0 Kudos