unformatted io and iostat

[james1]

Do you have an example? Since error handling generally works you'll need one to get an answer here.

James

[james1]

Dmitri, the program runs on my system and properly returns a read error under the circumstances you describe and completes successfully, however as you said the virtual memory consumed by the first read could easily hang a lot of systems (I saw an initial spike of well over 100Mb). I'd suggest that this is a problem with the RTL which Intel should take a look at.

James

[Intel_C_Intel]

Unformatted files with variable record lengths have to store the record length along with the data for each record. A typical implementation stores the record length as a 4 byte integer both before and after the data.

If you go into the file and delete a byte, the resulting
misalignment will unquestionably change one of these
record lengths, perhaps to a very large number.

This is speculation, but imagine what could happen in
the library routine that has to read one of the records.
It reads the corrupted record length, which says that
it needs some huge amount of memory if it is going
to hold the whole record in a buffer. It tries to get
the memory, and either bogs the whole system down or
crashes it depending on how robust the virtual memory
allocation scheme works on the particular OS.

[beckyp]

I have just had this same problem using Compaq Visual Fortran 6.6. I attempt to read a formatted file using the unformatted format and it does not give me an error message, it just keeps running and running and running.

Did you ever find a solution for this besides changing computers? My software has to run on a wide range of computers.

[forall]

nope... just dont do it :-)

but seriously, one would hope the iostat should somehow prevent such crashes. i havent tried this in ivf8 yet - nowdays a bit reluctant to cause windows to crash unnecesarily.

[Jugoslav_Dujic]

FWIW, once upon a time I managed to crash real-time critical SCADA server on Linuxjust by erroneously mismatching value/reference for an argument (instead of requesting allocation of 200 bytes (by value), I passed the argument by reference, requesting some 1,289,426,513 bytes; the server computer tried to obey :-D ).

There's no real cure, I'm affraid. In theory, Intel folks could re-tweak the run-time library to first go ahead n bytes and check whether there's another n at the end of the record, but I assume it would just slow things down.

Btw, is the end-of-record marker in unformatted files really used? This sample program shows otherwise -- I purposefully terminated the records with incorrectvalues but later unformatted read did not complain:

Code:

program Console5
implicit none
! Variables

character(10):: s
integer::       ierr

open(11, file="test", form="binary", action="write")
write(11) 10,"1234567890",#10000000
write(11) 10,"0987654321",#10000000
close(11)

! Body of Console5
open(11,file="test",form="unformatted",action="read")
read(11,iostat=ierr) s
read(11,iostat=ierr) s
close(11)

end program Console5

Jugoslav

[Steven_L_Intel1]

You mean the record length at the end of the record? It's there to support BACKSPACE.