Intel® Fortran Compiler
Build applications that can scale for the future with optimized code designed for Intel® Xeon® and compatible processors.
29400 토론

Segmentation fault - IOSTAT error codes 602 and 30

jirina
새로운 기여자 I
2,008 조회수

I am trying to open a binary file like this:

OPEN ( iunx, FILE='binary.d', ACCESS='DIRECT', STATUS='UNKNOWN',

+ FORM='UNFORMATTED', RECL=4, IOSTAT=iocheck, SHARE='DENYRW' )

The file might exist, but it does not have to. When I tried STATUS='OLD', I was getting Segmentation fault and I found out in idb that iocheck is 602, which means that STATUS='OLD' was used for a file which does not exist.

So, I changed the status to 'UNKNOWN' (default), expecting that iocheck will contain a value which would be error, allowing the application to continue, but it is severe(30) now, so the application stops with the segmentation fault again.

My source code (console application) was originally written for Windows, so maybe I am missing something what would explain why STATUS='OLD' worked OK in Windows and causes the segmentation fault in Linux. Does this mean that I should check the presence of a file before trying opening the file, e.g. using INQUIRE?

I am sorry if my question is too stupid, I am new to Linux and I am fighting with getting used to it now.

0 포인트
1 솔루션
TimP
명예로운 기여자 III
2,008 조회수

This looks like an out of stack space problem. You could check for that by running under debug, except that it would like occur at a different spot. Usual remedies, discussed several times on the form, include increasing stack limits, or heap-arrays compile switch.

원본 게시물의 솔루션 보기

0 포인트
6 응답
TimP
명예로운 기여자 III
2,009 조회수

If you have a different behavior on opening files between Windows and linux, it is likely to be a file name spelling problem. For example, under Windows, upper and lower case may be treated as equivalent, but they are not equivalent on linux, where the name you have in Fortran must agree exactly with the name on disk.

0 포인트
jirina
새로운 기여자 I
2,009 조회수

I know about the case sensitivity in Linux, but it is not my problem. I am dealing with situation that I am trying to open a file which does not exist on the disc. In Windows, I could process the error code of IOSTAT and e.g. return from the subroutine which was trying to open the file; however, the application stops with the segmentation fault in Linux without any chance to process this error.

I am using STATUS at many places in my source code, so I wonder if there is an easy solution rather than adding an explicit check whether the file exists.

0 포인트
TimP
명예로운 기여자 III
2,009 조회수

Neither the Fortran standard nor the ifort documents differentiate among these OS as far as status is concerned. The standard is clear that status='old' creates an error condition if the file doesn't exist, or unit is not connected. The standard leaves latitude as to how 'unknown' is implemented, but the ifort docs specify the usual behavior, that file creation will be attempted if it doesn't exist. Failure would most likely indicate lack of permission to create a file. It's probably more portable to check for file existence first so as to open as 'new' or 'old'. I can't think why you wouldn't be able to use iostat the same way as on Windows. If possible, you might submit a simple reproducer in a problem report on premier.intel.com.

0 포인트
jirina
새로운 기여자 I
2,009 조회수

Thank you for your kind help. I realized that the cause of the segmentation fault problem lies probably somewhere else. I realized that the fault occurs when the first statement in the subroutine is reached. It was OPEN in my case, but I added some code before the file is opened and the debugger stops at the first statement of the new code, right after the declaration of variables finishes. Now I need to find out why following code triggers the fault:

write(name,'(a,i2.2)' 'Transformer ', i

call find_binary_file_record ( 11, name, value, .true., new_value )

subroutine find_binary_file_record ( code, name, value, check_names, new_value )

with integer*4 code, character*25 name, real*8 value, logical*4 check_names, logical*4 new_value.

0 포인트
TimP
명예로운 기여자 III
2,009 조회수

This looks like an out of stack space problem. You could check for that by running under debug, except that it would like occur at a different spot. Usual remedies, discussed several times on the form, include increasing stack limits, or heap-arrays compile switch.

0 포인트
jirina
새로운 기여자 I
2,009 조회수

Indeed, increasing the stack size using 'ulimit -s unlimited' resolved my problem.

Thank you very much.

0 포인트
응답