Any idea what might cause runtime error 32 (invalid logical unit number)?

[Mark_Lewy]

This happens occasionally when we run several simulations (sim.exe) concurrently in one of our older releases:

forrtl: severe (32): invalid logical unit number, unit -221, file unknown
Image PC Routine Line Source
libifcoremd.dll 00007FFDC6BA5393 Unknown Unknown Unknown
sim.exe 00007FF7D9C617EC Unknown Unknown Unknown
sim.exe 00007FF7D99F104A Unknown Unknown Unknown
sim.exe 00007FF7DA174B92 Unknown Unknown Unknown
sim.exe 00007FF7DA1CD054 Unknown Unknown Unknown
KERNEL32.dll 00007FFE45AE7034 Unknown Unknown Unknown
ntdll.dll 00007FFE46902651 Unknown Unknown Unknown
30/06/21 11:05:44 Simulation engine exited code 32 (0x00000020)

I believe unit -221 is the (NEWUNIT=) logical unit for the log file, normally opened as "CON".

Needless to say, rerunning the offending simulation on its own succeeds

sim.exe was built with XE2019U5.

BTW, the current documentation for run time error 32 is
severe (32): Invalid logical unit number
FOR$IOS_INVLOGUNI. A logical unit number greater than 2,147,483,647 or less than zero was used in an I/O statement.

This needs updating to reflect the fact that NEWUNIT= returns a -ve logical unit number.

[Arjen_Markus]

Do you explicitly open a log file named "CON" via NEWUNIT=? That should not be necessary and as "CON" is one of the special file names under Windows, it may even be harmful. Why not use OUTPUT_UNIT (from the ISO_FORTRAN_ENV module)?

[Mark_Lewy]

Arjen, the program is driven by a job file that specifies paths for the various files it uses.  In this particular use case, the log file path is set to CON.   I can't say we have ever had any issues with this in the past.  Certainly, I have never encountered it in many debug and release build runs.  The user who observed this was running several short duration simulations concurrently, so I wonder if this is a concurrency issue in the Fortran RTL?

The run in question contains 380 simulations.  I've tried rerunning them on my laptop (16 threads) with 8 concurrent jobs.  Needless to say, no simulations failed.

[Steve_Lionel]

In situations such as this I don't take error messages literally (or exclusively). I'll also consider that data corruption may have occurred previously in the program that triggers a confusing error later.

[Mark_Lewy]

Steve, see my reply to Arjen above.

I agree that we should take this message with a pinch of salt, also data corruption seems highly unlikely to me in this particular case.

[Arjen_Markus · Accepted solution]

I was able to force such an error with the following program:

program opencon
    implicit none

    integer :: i, lun

    do i = 1,100
        open( newunit = lun, file = 'CON' )
        write(*,*) lun
        write(lun,*) lun
        close( lun )
        write(lun,*) 'writing to closed stdout', lun
    enddo
end program opencon

It produces:

        -129
        -129
forrtl: severe (32): invalid logical unit number, unit -129, file unknown
Image              PC                Routine            Line        Source
opencon.exe        00007FF7EDDC7CCF  Unknown               Unknown  Unknown
opencon.exe        00007FF7EDDC1194  Unknown               Unknown  Unknown
opencon.exe        00007FF7EDE163BE  Unknown               Unknown  Unknown
opencon.exe        00007FF7EDE16740  Unknown               Unknown  Unknown
KERNEL32.DLL       00007FFFD1E97C24  Unknown               Unknown  Unknown
ntdll.dll          00007FFFD2CED721  Unknown               Unknown  Unknown

So, could it be that at some point (in a particular corner of the calculation) the program closes the file opened as -221 and then attempts to write to the console (standard output)? (It works fine, opening and closing "CON" if I remove the write statement outside the pair of open/close statements)

[Mark_Lewy]

Thanks Arjen, that could well be it - the code I have mixes output to the log unit (opened as "CON") and to output_unit.