IOSTAT 30 problems

[Simon_Geard]

Is it possible to analyze the cause of IOSTAT=30 errors from an open statement?

We have

          inquire(file=zfile,exist=file_exists,opened=file_open, number=u,
     &    action=action)
          OPEN(NEWUNIT=IUNIT, ACCESS='SEQUENTIAL',ERR=999,FILE=ZFILE,
     &        FORM='FORMATTED',IOSTAT=IOSTAT,STATUS='REPLACE',iomsg=msg)

which gets executed many times, with the parameters in the inquire statement always being returned as .true.,.false.,-1,'UNDEFINED'

However at the end of an analysis step when the routine containing this code is executed the iostat error is set to 30. Subsequent calls to open other files in the same directory then fail in the same way. The iomsg just says 'open failure' (along with the file name and unit number) so that isn't very helpful. I'm fairly sure the problem must be in the code called prior to this but I've no idea how to proceed. Is there a way of finding out what the particular problem is that has caused this error?

Thanks.

[Steven_L_Intel1]

Yes - call the ERRSNS intrinsic subroutine (an extension) - this will get you the system error code which you can then look up in the MSDN Library list of Windows errors.

[Simon_Geard]

Thanks. I've tried that and I'm getting 1450, which according to MS is

ERROR_NO_SYSTEM_RESOURCES => Insufficient system resources exist to complete the requested service.

 

 

The routine (Fortran) that that gets called prior to this error does a large amount of  file i/o but it is not new code. The ascii file being processed contains 21010709 lines. Are there any pitfalls in Fortran i/o that could lead to this problem?

[Steven_L_Intel1]

Nothing specifically Fortran related, but if you have lots of files opened you may have run out of channels, a system resource, It may be helpful to run a system monitoring tool such as Windows' perfmon to look at resources used by your application.

[jvandeven]

I have experienced a similar problem to the issue cited in this thread (see the thread here).  Was a resolution to this problem found?  If so, what was it?

[Simon_Geard]

I don't have a resolution to this problem but I did find out more. The problem only ocurrs when running the code with VS. Even starting using 'start without debugger' causes the problem, but running the program directly is ok. After stepping through the code it looks as if simple intrinsic calls in a subroutine (e.g.index(...)) consume a resource handle that never gets released so with the very large number of calls we have in our code the number of available resource handles gets exhausted.

I haven't tried it in v16 proper yet.

[Steven_L_Intel1]

Take a look at https://software.intel.com/en-us/forums/topic/591225 and my instrumentation of the test program - see if building against the non-multithreaded library changes things.

[Simon_Geard]

I've done that and it does reproduce the problem. With ifort handles_bug.f90 /threads I get

handles_bug.exe
          11
          16
        2016
        4016
        6016
        8016
       10016
       12016
       14016
       16016
       18016
       20016
       22016
       24016
       26016
       28016
       30016
       32016
       34016
       36016
       38016
       40016
       42016
       44016
       46016
       48016
       50016
       52016
       54016
       56016
       58016
       60016
       62016
       64016
       66016
       68016
       70016
       72016
       74016
       76016
       78016
       80016
       82016
       84016
       86016
       88016
       90016
       92016
       94016
       96016
       98016
      100016
      102016
      104016
      106016
      108016
      110016
      112016
      114016
      116016
      118016
      120016
      122016
      124016
      126016
      128016
      130016
      132016
      134016
      136016
      138016
      140016
      142016
      144016
      146016
      148016
      150016
      152016
      154016
      156016
      158016
      160016
      162016
      164016
      166016
      168016
      170016
      172016
      174016
      176016
      178016
      180016
      182016
      184016
      186016
      188016
      190016
      192016
      194016
      196016
      198016
 --> check number of process handles in Windows Task Manager

which is 200,016

whereas with ifort handles_bug.f90 all the handle counts are 11 which is the same as the number of process handles reported by the Windows Task Manager.

[jimdempseyatthecove]

Is there something not said about your program that could be causing the explosion in handles?

IUNIT not being closed
INQUIRE at fault (comment out INQUIRE, use STATUS='UNKNOWN' in OPEN)

Jim Dempsey

[Steven_L_Intel1]

Did you just run the same program from the other thread? That isn't useful. What I wanted you to do was to take the code that captures the handle count and add it to your own program, to see if handle counts are the issue. Then see if you can determine which operation causes the count to increase.

[Simon_Geard]

Yes I did. I'll try to include the handle count code and report back.

[jvandeven]

Seems that there is a problem with the write statement in PSXE16.0 when using certain libraries.  In my case, however, the problem seems to arise whether I use the VS debugger (2010/2015), or alternative libraries...

[Simon_Geard]

I have found this problem in another one of our applications and have submitted it to Premier Support as a reproducer.

[mecej4]

sgeard@cad-schroer.co.uk wrote:

Yes I did. I'll try to include the handle count code and report back.

Others covered more or less the same topic in https://software.intel.com/en-us/forums/intel-visual-fortran-compiler-for-windows/topic/593961#comment-1841125 . A fix is in the works.