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