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

Error when reading file, system message number 1450


Hello, i am having a rahter obscure error. I am trying to read a file, which works for thounsands of times. But after a while I get this error:

So there are two errors here: The first on refers to the Pardiso solver (I am not using the MKL Pardiso solver but the standalone version 6.0.0 for performace reasons.) It fails to find or open the license file, which it has already found, opened and read for millions of times during the program execution.  Then there is a second error regarding the opening of another file, here is the code snippet where the error is triggered:  

inquire(file=name2(1:TRIM_LENGTH2), exist=exist_flag)
  if (exist_flag) then
                OPEN(UNIT=12, FILE=name2(1:TRIM_LENGTH2), access="stream")
                READ(12) process_id_saved

This file has also been opened, read and closed millions of times. The error code 1450 translates to ERROR_NO_SYSTEM_RESOURCES. The program is using only 60 MB of RAM, the file I am reading is only a few bytes, it contains the current process id. The file is written during the first loop:


                    OPEN(UNIT=13, FILE=name2(1:TRIM_LENGTH2), form="unformatted", ACTION="write", STATUS="replace", access="stream")
                    WRITE(UNIT=13) process_id

I did some digging on the internet and found out that ERROR_NO_SYSTEM_RESOURCES could refer to a full IO Buffer, but i am closing every file I read or write with close(). Maybe the pardiso solver does not close the license file after reading it? Unfortunately i can not look into its source code. Is it possible to emtpy the bugger manually?




0 Kudos
5 Replies
New Contributor II

What is the STATUS of the OPEN on unit 13?

0 Kudos
Black Belt

The ERROR_NO_SYSTEM_RESOURCES is a Windows error indicating it ran out of "something" necessary to open the file. The resource is not necessarily an I/O buffer, but it can also be another object identified by a Windows handle. What version of Windows are your running (and if it is Win32 or x64)?

In reading:

You have to read more into the explanation than what is said. Discount the size limitation for a moment (your buffer size is likely under what is mentioned). There are two (of many) requirements for the open to succeed (in case where FILE_FLAG_NO_BUFFERING is used). a) A physical RAM buffer of sufficient size must be available, and b), a suitable virtual memory address must be available. The article implies only a). You did not state as to if you have a 32-bit application or 64-bit application. If 32-bit your heap may have been fragmented to have grown to the point where it is unable to obtain a suitable virtual address (aligned malloc to page size).

Indicates a named pipe issue, there are many others...

If your application is opening files millions of times, consider opening the file once, and then re-positioning the file pointer. Depending on your access mode this may be via REWIND or POS=1.

Jim Dempsey



0 Kudos
Black Belt

I had noticed in some past versions of IFort that file access operations had small memory leaks (a few bytes per file operation statement). Normally, with less than, say, a hundred such statements encountered in a run, that could cause the leak of less than a kilobyte, which is probably tolerable. With millions of file openings and closings, that would no longer be true. 

Which version of IFort did you use?

0 Kudos
Honored Contributor II

As per the last post are you using compiler 16.0? If so this problem can arise .


0 Kudos
Valued Contributor I

This is the equivalent WinAPI code to what INQUIRE() is doing, note the call to FindClose to fix a memory leak:

RECURSIVE FUNCTION file_exists (fname) RESULT (size)
	TYPE(T_WIN32_FIND_DATA)			:: fdata
	CHARACTER(LEN=*),INTENT(IN) 	:: fname  ! full pathname to file
	INTEGER(HANDLE)                 :: ihandl
	INTEGER							:: size, rval, nc
	size = -1
	nc = chcnt(fname, LEN(fname))
	IF (nc > 5) THEN
		ihandl = FindFirstFile (fname, fdata)
			size = fdata%nFileSizeLow

			! added in v5.024; without this we had a memory leak
			rval = FindClose (ihandl)
END FUNCTION file_exists

I strongly endorse the suggestion to open the file once and leave it open.

0 Kudos