- 신규로 표시
- 북마크
- 구독
- 소거
- RSS 피드 구독
- 강조
- 인쇄
- 부적절한 컨텐트 신고
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.
- 신규로 표시
- 북마크
- 구독
- 소거
- RSS 피드 구독
- 강조
- 인쇄
- 부적절한 컨텐트 신고
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.
링크가 복사됨
- 신규로 표시
- 북마크
- 구독
- 소거
- RSS 피드 구독
- 강조
- 인쇄
- 부적절한 컨텐트 신고
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.
- 신규로 표시
- 북마크
- 구독
- 소거
- RSS 피드 구독
- 강조
- 인쇄
- 부적절한 컨텐트 신고
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.
- 신규로 표시
- 북마크
- 구독
- 소거
- RSS 피드 구독
- 강조
- 인쇄
- 부적절한 컨텐트 신고
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.
- 신규로 표시
- 북마크
- 구독
- 소거
- RSS 피드 구독
- 강조
- 인쇄
- 부적절한 컨텐트 신고
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.
- 신규로 표시
- 북마크
- 구독
- 소거
- RSS 피드 구독
- 강조
- 인쇄
- 부적절한 컨텐트 신고
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.
- 신규로 표시
- 북마크
- 구독
- 소거
- RSS 피드 구독
- 강조
- 인쇄
- 부적절한 컨텐트 신고
Indeed, increasing the stack size using 'ulimit -s unlimited' resolved my problem.
Thank you very much.