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

Segmentation fault - IOSTAT error codes 602 and 30

jirina
Nuevo Colaborador I
2.026 Vistas

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 kudos
1 Solución
TimP
Colaborador Distinguido III
2.026 Vistas

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.

Ver la solución en mensaje original publicado

6 Respuestas
TimP
Colaborador Distinguido III
2.027 Vistas

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.

jirina
Nuevo Colaborador I
2.027 Vistas

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.

TimP
Colaborador Distinguido III
2.027 Vistas

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.

jirina
Nuevo Colaborador I
2.027 Vistas

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.

TimP
Colaborador Distinguido III
2.027 Vistas

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.

jirina
Nuevo Colaborador I
2.027 Vistas

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

Thank you very much.

Responder