In Windows 10, with Visual Studio 2017 and Intel® Parallel Studio XE 2019 Update 5, the following code crashes on the last line.
Here is a bit of the code:
c --- (process to generate ENTDT here)
ENTDT = '30120331' ! Ignore process
Write (AString,'(2a)') ' The Date=', ENTDT
Call WINMSG (AString)
Read (ENTDT, '(i4,2i2)', IoStat = i ) iYear, Imonth, Iday
The output line written to a diagnostic file via the WINMSG function yields the following output:
" The Date=30120331"
The crash "site" appears as shown in the attached file, ENTDT-2.png, and the line 1040 is the Read statement shown above. The crash does not seem to make sense because we are reading 8 characters, and that is what the format statement says.
How can the cause of this problem be diagnosed ? (Sure looks like the same type of problem reported by Bart Jackson).
P.S. To Dr. Fortran: Source code was submitted to Support over a month ago, waiting for a reply. Can't put the code here as it is also *private*.
How are iYear, iMonth and iDay declared? If any of them are arrays, you'd get this behavior.
Can you construct a small, self-contained test case that shows the problem? It should be easy based on what you showed above. Often the attempt to do so reveals that the real problem is elsewhere.
Steve Lionel (Ret.) (Blackbelt) wrote:
[...] Often the attempt to do so reveals that the real problem is elsewhere.
In support of Steve's comment: The attached image shows a runtime IO-error message, but the suspected read-statement specifies iostat which ought to supress such messages. Unless, of course, the error-message is generated errorneously, indicating a bigger compiler-issue.
I often get it lately that the program just shuts down. It usually is a write statement with an error in the format. Even including an error statement number to (ie err=250) and iostat it still happens. I have learnt by now to make sure that the format is correct. With error I mean something like trying to write an I4 where the format is I3.
Place a break point on the offending Read. Then from the debugger, tell us all about the variables: i, iYear, Imonth, Iday
This includes type and prior contents.
This also happens in the code with no call to WINMSG. I have created a reproducer:
SUBROUTINE EXPIRY_DATE ( IYEAR, IMONTH, IDAY ) CHARACTER ENTDT*8 INTEGER I INTEGER IYEAR, IMONTH, IDAY ENTDT = '30120331' READ (ENTDT, '(I4,2I2)', IOSTAT = I ) IYEAR, IMONTH, IDAY END SUBROUTINE EXPIRY_DATE PROGRAM TEST CALL EXPIRY_DATE END
Thanks to all for your comments. Support has just confirmed that this problem will be "escalated" to be fixed.
Here is a short demo as provided by IGOR:
SUBROUTINE EXPIRY_DATE ( IYEAR, IMONTH, IDAY )
INTEGER IYEAR, IMONTH, IDAY
ENTDT = '30120331'
READ (ENTDT, '(I4,2I2)', IOSTAT = I ) IYEAR, IMONTH, IDAY
END SUBROUTINE EXPIRY_DATE
That is not a valid code since I didn't pass arguments to a subroutine. The code that fails in the application looks like this:
Subroutine EXPIRY_DATE ( iYear, Imonth, Iday ) !MS$ATTRIBUTES DLLEXPORT :: EXPIRY_DATE character ENTDT*8 integer i integer iYear, Imonth, Iday ENTDT = '30120331' Read (ENTDT, '(i4,2i2)', IoStat = i ) iYear, Imonth, Iday end subroutine EXPIRY_DATE program test integer iYear, Imonth, Iday call EXPIRY_DATE (iYear, Imonth, Iday) end
This small test doesn't show a problem. Note that it is reproducible with /Od optimization level (disabled). I will continue to work on the full project to find a smaller reproducer.
The execution goes further if I split the read statement to 2:
Read (ENTDT, '(i4)', IoStat = i ) iYear Read (ENTDT, '(2i2)', IoStat = i ) Imonth, Iday
However, it then fails on similar read statement later:
Character Ch4*4 real x ENTDT = '30120331' Ch4='6.1' Read (Ch4,'(f4.0)')
The optimization level doesn't change the behavior. In this case it is compiler with Od (optimization disabled).
Full compiler options list:
ifort test.f90 /nologo /debug:full /Od /fpp /f77rtl /fpscomp:filesfromcmd /fpscomp:ioformat /fpscomp:logicals /fpscomp:general /warn:declarations /warn:unused /align:rec4byte /align:commons /names:uppercase /iface:stdref /iface:mixed_str_len_arg /traceback /check:bounds /check:uninit /libs:static /threads /dbglibs /c
Yes, it looks like a stack corruption. I have found that for the exception with Read (Ch4,'(f4.0)') the value of Ch4 is garbage, as well as iteration variable and many other vars.