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

How to Diagnose "impossible" crash

bbradley
Beginner
1,319 Views

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:


      Character ENTDT*8
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*.

0 Kudos
15 Replies
Steve_Lionel
Honored Contributor III
1,319 Views

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.

0 Kudos
Ferdinand_T_
New Contributor II
1,319 Views

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.

0 Kudos
GVautier
New Contributor II
1,319 Views

"

0 Kudos
Neels
New Contributor II
1,319 Views

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.

0 Kudos
jimdempseyatthecove
Honored Contributor III
1,319 Views

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.

Jim Dempsey

0 Kudos
jimdempseyatthecove
Honored Contributor III
1,319 Views

Additionally, if you comment out the call to WINMSG does the error occur?

If NOT, then you have an interface declaration error or omission.

Jim Dempsey

0 Kudos
Igor_V_Intel
Employee
1,319 Views

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

 

0 Kudos
bbradley
Beginner
1,319 Views

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 )
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
 

0 Kudos
GVautier
New Contributor II
1,319 Views

Call and subroutine arguments does'nt conform. How can this ever work?

0 Kudos
Igor_V_Intel
Employee
1,319 Views

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.

0 Kudos
GVautier
New Contributor II
1,319 Views

The fact that optimization level change the behaviour may signify that the source of the problem is probably a stack corruption elsewhere in the program.

 

0 Kudos
Igor_V_Intel
Employee
1,319 Views

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)')

 

0 Kudos
Igor_V_Intel
Employee
1,319 Views

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

0 Kudos
GVautier
New Contributor II
1,319 Views

This kind of "impossible" error is generally symptomatic of a stack corruption elsewhere.

 

0 Kudos
Igor_V_Intel
Employee
1,319 Views

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.

0 Kudos
Reply