forums.silverfrost.com

DanRRight · Posted: Sun Oct 22, 2023 9:04 am Post subject: Invalid FP operation, crash

From my series of "Saturday devilry". It harasses me like that 10 times a day. This one already killed a lot of my time today

Never had this error before.
Here what SDBG shows: crash on this line when reading some file. Notice err= and end= are present but not saved from crash nevertheless. Why?

The data is here:

How this number which must be 0 by default ( i set element #6 equal to 0 for every write) became corrupted i do not know. Devilry.

So how to avoid the crash? I suspect the number was larger than real*4 allows. Or this was a denormal number. But anyway does FTN95 have the facility to deal with it? I can try substitute Partcl4 with some real*8 variable (though this is unformatted read, that means it is not that straightforward to do) , check all is fine and copy its content into Partcl4 but this would slow down my read tremendously, it is already 1/3 of my day time losses. That would not help anyway if the place has a lot of garbage

Kenneth_Smith · Posted: Mon Oct 23, 2023 11:00 am Post subject:

The first thing I see here is that FMT is missing in the read statement.

mecej4 · Joined: 31 Oct 2006 Posts: 1886

DanRRight · Posted: Mon Oct 23, 2023 5:38 pm Post subject:

This was not a variable limit problem, it was something else, some so stinky junk that even real*8 i tried to read it crashed the code Smile

Suspect what happened is that my external ssd drive fell during transfer (cables, cables everywhere, lots of cables) and electric noise caused something. What can happen in these 4 bytes which will put the code down? My impression was that some other compilers mark such places as a NOT A NUMBER and somehow there probably exist mechanism to not to crash the READ

wahorger · Joined: 13 Oct 2014 Posts: 1217 Location: Morrison, CO, USA

It has been my experience that the ERR= applies mainly to violations of an input format conversion (which an unformatted file does not have) or a bad record index used (for ACCESS="DIRECT"). If you try to read/write too much from/to a direct access file, that will be trapped as well. Very little else.

Stated another way, ERR= is great for formatted files!

ERR= It may also catch an end-of-file, and for that you'd have to use IOSTAT (=57) to get at the true cause.

There are ways of looking at the raw data in a file such as this. Perhaps that might explain why only one of thousands exhibits this behavior.

JohnCampbell · Joined: 16 Feb 2006 Posts: 2554 Location: Sydney

Dan,

Can you assist to make a simple reproducer, by providing a link to the Partcl4 data.

A test program could be like

DanRRight · Posted: Thu Oct 26, 2023 7:12 pm Post subject:

John,
I have 1-2 GB file with this error. I can send it to everyone who are interested.

I can create the Fortran code to read it or anyone can easily figure out how to read it as it has delimiter between the header and the data consisting of character variable containing 256 minus signs while the following it data is just eleven 4-bytes real numbers per each record, exactly like in the picture at the beginning this thread. The beauty of this method is that despite it is binary file everyone can open it with the text editor and see not just the garbage of binary content but the usual ASCII memo i left in the header about this specific variant of data. Header for example may look like this

JohnCampbell · Joined: 16 Feb 2006 Posts: 2554 Location: Sydney

Dan,

Am I understanding that the file is an unformatted sequential binary file, using FTN95 format of 1 or 5 byte header/trailer format.
There appear to be a mixture of record types.

However, there is a large chunk of 44-byte records (at least 8,315 records of 44 bytes > 357 kBytes of data) that is causing the problem.

You could read each of these records into a 44 byte field ( even character*44 record ), then use TRANSFER to copy into real*4 :: real_buffer(11) and check each entry, especially "if ( real_buffer(6) /= 0 )"
This approach could at least give you what hex values are in Partcl4(6,8315).
You implied they should be zero, but something went wrong ?

Even reading these 44-byte records as character and dumping them into another 360kbyte binary file would overcome any invalid real number errors. Note these records have a 1-byte header/trailer in FTN95 format files.

Sorry, I am not a believer in "Saturday devilry", so apply a systematic check of the problem.

Also puzzled as to how you edit the file's 256 character project header, without corrupting the FTN95 unformatted sequential file format ? Could this process corrupt the file