run time error forrtl:severe <8>

[Hanbing_P_]

    Recently, I always meet the run time error "forrtl : severe <8>: internal consistency check failure, file for_intrp_fmt.c, line 1474" when using IVF 2013 integrated with VS2012. The error appears and disappears strangely, which means it doesn't appear every time but sometimes, and once it appears , it may disappear after I clean up the solutions several time but this way does not work out every time. So, it has almost driven me crazy because I know nothing about how to figure it out .I am looking forward some possible solutions about it . Thanks a lot! By the way ,even though the error appears randomly ,but it always occurs at file I/O expression like this:''  READ (iunit,'(i6,14x,a)') iver,line ''(I am sure of the consistency of the format in the file with the format description )

[Steven_L_Intel1]

This error means that the program has corrupted the memory of the run-time library's data structures. Typically this is due to a programming error in the application, but due to the way Windows does address space randomization, this sort of error can be difficult to reproduce, and this makes it even harder to diagnose.

Probably the first thing I would try is to run this through the memory checking analysis of Intel Inspector XE. If you don't want to do that, then turn on all available error checking (/check:all /warn:interface) and then start selectively removing parts of the program to see where the corruption may be occurring.

[Hanbing_P_]

    First of all, Steve , thank you very much for your help.

    I follow your opinion, run my project (named brd2sp3) through the memory checking analysis of Intel Inspector XE 2013. But I till can not find out  the reason. 

The code where a "Uninitialized memory access" type error is reported  in file F_GetValidFileUnit.f90:79 is as follow:

  OPEN(UNIT=f_getValidFileUnit,FILE=filename(1:len_trim(filename)),STATUS=stat,FORM=formed,POSITION=posit,ACCESS=acce,IOSTAT=ios)

I do not know what' s worry with this !

Can give me some opinions about what kind of programming error may exist in my code ?

I will very appreciate that.

[mecej4]

Have you tried printing out the values of the variables f_getValidFileUnit, filename, formed, posit and acce before the OPEN statement, to see if they have been defined? The Inspector screenshot clearly shows that an uninitialized variable is used on line 79. Secondly, you may try to run your program without an IOSTAT=ios clause in the OPEN statement in order to let the Fortran I/O system display error messages related to the attempted opening of the file.

[Steven_L_Intel1]

Unfortunately, I don't think that the findings of Inspector XE are useful here. I think the OPEN issues are not in fact problems. What you need to be looking for is writes out of bounds or to arguments passed incorrectly. 

[Hanbing_P_]

     Steve, I agree with you, maybe the OPEN expression is all right !  You say that I should go looking for ''writing out of bounds'' or ''incorrectly passing arguments'' ,but where should I start ? writing out of bounds like what, ARRAYs? check every functions and subroutines for possible incorrectly passing arguments?  Because there are many arrays , functions and subroutines in my project, If I don't know where are the possible error sources, It will be very hard for me to figure it out . When the error happens, it definitely interrupts at the WRITE/READ expression, doesn't it mean something? I am still suffering from the strange error. So, I am sorry to trouble you once more.Thank you so much for your patience.  

[Steven_L_Intel1]

The way I generally investigate such problems is to start removing pieces of the program and see if I can identify the smallest bit of code which, when removed, causes the error to go away. Then I look carefully at what that code is doing. That the error happens randomly suggests that it is sensitive to data layout - Windows changes the start of the stack and dynamic memory each time you run the program. This is not an easy problem to track down.

[Hanbing_P_]

    Steve, I miss another point ,when my program interrupts at the statement "READ ( iunit, '(i6,14x,a)' ) iver, line", I modified it to "READ (iunit, *)  line", this error went away(Sure, the way it read the file  is not that I wanted it to be). Then, the error may occurs at another  READ statement like before,

but if I replace the FORMAT description string  with *, such as modified " READ ( iunit, '(a)' ) line "  to " READ ( iunit, * )  line" ,the error just went away. I have no idea that if  this means something.

    By the way , I have checked my code, I can hardly find anything that may cause problems like "array out of bounds" and "incorrectly passing arguments ".

[mecej4]

So far, you have described some bits of the code, and the efforts to identify the problem have failed. If possible, post the code, and someone may be able to see things in it that you did not.

[Hanbing_P_]

FUNCTION f_GetValidFileUnit(iunit0,filename,lexist,stat,formed,posit,acce)

USE par
IMPLICIT NONE


INTEGER(IT) :: f_GetValidFileUnit 
INTEGER(IT) :: iunit0             
CHARACTER(*):: filename           
CHARACTER(*):: stat               
CHARACTER(*):: formed
CHARACTER(*):: posit
CHARACTER(*):: acce  
LOGICAL(LG) :: lexist            

 
  INTEGER(IT) :: iunit,ios
  CHARACTER(256):: string
  LOGICAL(LG) :: lDebug
  COMMON /dDebug/ lDebug

 
  f_getValidFileUnit=0
  ios=0
  iunit=iunit0
  IF (iunit0 .LE. 10) iunit=10          
  
  DO WHILE ( f_getValidFileUnit .EQ. 0)
    INQUIRE(UNIT=iunit, NAME=string)    
    IF(LEN_TRIM(string) .NE. 0) THEN
      iunit = iunit+1 
    ELSE
      f_getValidFileUnit = iunit        
    ENDIF
  ENDDO

  OPEN(UNIT=f_getValidFileUnit,FILE=filename(1:len_trim(filename)),STATUS=stat,FORM=formed,POSITION=posit,ACCESS=acce,IOSTAT=ios)
  IF (ios.NE.0) THEN 
    IF (lexist) THEN  
      WRITE(*,*) '***ERROR: open file, ',filename(1:len_trim(filename))
      lexist=.FALSE.
      CALL EXIT(1)
    ENDIF
  ELSE
    lexist=.TRUE.   
  ENDIF

RETURN

END FUNCTION f_GetValidFileUnit

This is the f_GetValidFileUnit function.

[JVanB]

That f_GetValidFileUnit function is obsolete. Get rid of it and replace with OPEN(newunit=iunit...

Also don't worry about filename(1:len_trim(filename)). You could replace this with trim(filename), but the Fortran processor trims the name for you anyway. The hard thing to do in Fortran is to open a file with trailing spaces in its name.

I don't know if this will help you with your problem, though. Definitely try using the features of the compiler to automatically check interfaces and array bounds to see if it can spot anything for you.

[Hanbing_P_]

Thanks for your  reply !

     The f_GetValidFileUnit function is written by myself, what's wrong with it? Do there any problem with it ?

And how can I "try using the features of the compiler to automatically check interfaces and array bounds"?

I don't know exactly how to do this !

[Hanbing_P_]

Thanks for your  reply !

     The f_GetValidFileUnit function is written by myself, what's wrong with it? Do there any problem with it ?

And how can I "try using the features of the compiler to automatically check interfaces and array bounds"?

I don't know exactly how to do this !

[JVanB]

I can't do everything for you, but I tried typing how do i do bounds checking in intel visual fortran into google and the second link I came up with was https://software.intel.com/en-us/articles/tips-for-debugging-run-time-failures-in-intel-fortran-applications which seems quite useful.

The point about the f_GetValidFileUnit function is that it searches for a valid unit number you can open, but the compiler already can do this for you. Look in the User and reference guide for the Intel Fortran compiler 15.0, language reference, file operation I/O statements, OPEN statement specifiers, NEWUNIT specifier.

[mecej4]

Hanbing P wrote:
The f_GetValidFileUnit function is written by myself, what's wrong with it? Do there any problem with it ?

What Repeat Offender is telling you is that the capability (that your not-yet-working function appears to be designed for) is already present in the language in OPEN(NewUnit=.., ...). What, then, is the motivation for writing your own code to do the same task?

Secondly, you have given only the source code of the function subprogram. There is nothing wrong with it that one can see immediately, and I received a return value of 10 for the unit when I called it with

iu=f_GetValidFileUnit(-100,'xunit.f90',lex,'OLD','FORMATTED','ASIS','SEQUENTIAL')
write(*,*)iu

Note that 'xunit.f90" is the name I gave to the source file.

Since you ran into a program crash, suspicion should be directed to the values of the arguments with which you called the function, about which you gave no information. It is by no means certain that the code in the function covers all the possible combinations of values of the arguments, in particular calls with INTENT(OUT) arguments that have not been defined before the function invocation.

[Hanbing_P_]

mecej4 wrote:

Quote:

Hanbing P wrote:

The f_GetValidFileUnit function is written by myself, what's wrong with it? Do there any problem with it ?

What Repeat Offender is telling you is that the capability (that your not-yet-working function appears to be designed for) is already present in the language in OPEN(NewUnit=.., ...). What, then, is the motivation for writing your own code to do the same task?

Secondly, you have given only the source code of the function subprogram. There is nothing wrong with it that one can see immediately, and I received a return value of 10 for the unit when I called it with

iu=f_GetValidFileUnit(-100,'xunit.f90',lex,'OLD','FORMATTED','ASIS','SEQUENTIAL')
write(*,*)iu

Note that 'xunit.f90" is the name I gave to the source file.

Since you ran into a program crash, suspicion should be directed to the values of the arguments with which you called the function, about which you gave no information. It is by no means certain that the code in the function covers all the possible combinations of values of the arguments, in particular calls with INTENT(OUT) arguments that have not been defined before the function invocation.

The reason why i 

The function f_GetValidFileUnit was written many years ago. What do you mean about  " It is by no means certain that the code in the function covers all the possible combinations of values of the arguments, in particular calls with INTENT(OUT) arguments that have not been defined before the function invocation" 

[Hanbing_P_]

As you can see , the result of Inspector seems to tell that there is something wrong with the function f_GetValidFileUnit ,but I can not figure out what's wrong with it . So, I want to make sure that whether the error comes from the function.

And, even I replace it by OPEN( NEWUNIT=iunit, ....), the error still occurs! 

[mecej4]

You will need to provide a complete example code that exhibits the crash that you described. Whether a crash happens or not is dependent on the arguments that are passed to the function. Crashes are usually caused by programmer error, and much more often than bugs in the Fortran runtime.

I gave you an example where the arguments are all literals, and no crash occurred. Please show us a set of arguments that do cause a crash, and then we can look for reasons why the crash occurs. It is much harder to prove or disprove that a crash will or will not occur regardless of the values of the arguments passed to the function.

[Hanbing_P_]

mecej4 wrote:

You will need to provide a complete example code that exhibits the crash that you described. Whether a crash happens or not is dependent on the arguments that are passed to the function. Crashes are usually caused by programmer error, and much more often than bugs in the Fortran runtime.

I gave you an example where the arguments are all literals, and no crash occurred. Please show us a set of arguments that do cause a crash, and then we can look for reasons why the crash occurs. It is much harder to prove or disprove that a crash will or will not occur regardless of the values of the arguments passed to the function.

As I said before, the strange error doesn't occur every time even nothing has been changed.So, I don't know how to provide the complete information you need. And I have tried to turn on all the run time check option, but no special error was reported but "forrtl: severe<8>:internal consistency check failure, file for_intrp_fmt.c, line 1474." I don't know what it exactly means.The way how I use the function f_GetValidFileUnit is like the follow expression:

                   lfn = f_GetValidFileUnit(10,fln,lFind,'OLD','FORMATTED','ASIS','SEQUENTIAL')

Does there something wrong with this ?

Should I describe the situation where the error occurs every time ? After I open a file(the return value of OPEN tells the success), when I try to WRITE or READ with a format specifier like WRITR(iunit,FMT='...',...) or READ(iunit, FMT='...',...),the program interrupt and give the message" forrtl: severe<8>:internal consistency check failure, file for_intrp_fmt.c, line 1474." Although, the error doesn't occur every time , once it does , it must be the situation. 

[mecej4]

If, before the subroutine call

                        lfn = f_GetValidFileUnit(10,fln,lFind,'OLD','FORMATTED','ASIS','SEQUENTIAL')

the actual argument, lFind, had the value .FALSE. (or, for various reasons, might have been interpreted as .FALSE.), and the OPEN statement in the function failed (IOS not zero after OPEN), your function would behave as if the OPEN had succeeded -- no error message would be issued, and the function would return the unit number for which the OPEN had failed. Subsequent READ/WRITE statements to the unit returned by your function would cause runtime errors.

I have a suspicion that when Inspector warned you about uninitialized memory access (see #3) the reason was that lFind had not been assigned a value before being used in line 39 of the listing in #10.

It appears that the function has been coded with an assumption that may not have been satisfied when it was called. If the third argument has the value .TRUE., the fourth argument must be 'OLD', and if the fourth is 'OLD', the third must be .TRUE.

If this assumption is not satisfied or the third argument has not been defined before calling the function, the program will probably fail.

[Hanbing_P_]

mecej4 wrote:

If, before the subroutine call

                        lfn = f_GetValidFileUnit(10,fln,lFind,'OLD','FORMATTED','ASIS','SEQUENTIAL')

the actual argument, lFind, had the value .FALSE. (or, for various reasons, might have been interpreted as .FALSE.), and the OPEN statement in the function failed (IOS not zero after OPEN), your function would behave as if the OPEN had succeeded -- no error message would be issued, and the function would return the unit number for which the OPEN had failed. Subsequent READ/WRITE statements to the unit returned by your function would cause runtime errors.

I have a suspicion that when Inspector warned you about uninitialized memory access (see #3) the reason was that lFind had not been assigned a value before being used in line 39 of the listing in #10.

It appears that the function has been coded with an assumption that may not have been satisfied when it was called. If the third argument has the value .TRUE., the fourth argument must be 'OLD', and if the fourth is 'OLD', the third must be .TRUE.

If this assumption is not satisfied or the third argument has not been defined before calling the function, the program will probably fail.

Yes, you are right. What you pointed out maybe a possible bug , but I have checked the code, no the situation you put forward is found.

And furthermore, I changed the function to make sure the condition you just point will never happen ,like follow:

FUNCTION f_GetValidFileUnit(iunit0,filename,lexist,stat,formed,posit,acce)

USE par
IMPLICIT NONE


INTEGER(IT) :: f_GetValidFileUnit 
INTEGER(IT) :: iunit0             
CHARACTER(*):: filename           
CHARACTER(*):: stat               
CHARACTER(*):: formed
CHARACTER(*):: posit
CHARACTER(*):: acce  
LOGICAL(LG) :: lexist            

 
  INTEGER(IT) :: iunit,ios
  CHARACTER(256):: string
  LOGICAL(LG) :: lDebug
  COMMON /dDebug/ lDebug

 
  f_getValidFileUnit=0
  ios=0
  iunit=iunit0
  IF (iunit0 .LE. 10) iunit=10          
  
  DO WHILE ( f_getValidFileUnit .EQ. 0)
    INQUIRE(UNIT=iunit, NAME=string)    
    IF(LEN_TRIM(string) .NE. 0) THEN
      iunit = iunit+1 
    ELSE
      f_getValidFileUnit = iunit        
    ENDIF
  ENDDO

  OPEN(UNIT=f_getValidFileUnit,FILE=filename(1:len_trim(filename)),STATUS=stat,FORM=formed,POSITION=posit,ACCESS=acce,IOSTAT=ios)
  IF (ios.NE.0) THEN 
      WRITE(*,*) '***ERROR: open file, ',filename(1:len_trim(filename))
      lexist=.FALSE.
      CALL EXIT(1)
  ELSE
    lexist=.TRUE.   
  ENDIF

RETURN

END FUNCTION f_GetValidFileUnit

But the "forrtl: severe<8>:internal consistency check failure, file for_intrp_fmt.c, line 1474." still appears .