On Feb 3 11:24, Jerry DeLisle wrote:
I have confirmed this problem on Cygwin reported here:
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35063
I am not very familiar with the windows environment. Having patched most
of the gfortran I/O library in the last 2-3 years I can say that we do a
lot of memory allocation for I/O.
On Linux based systems we do not see any issues (checked with valgrind).
This problem acts like a failure to free memory. I do not know what is
meant by the term "handle" other than a pointer to an allocated block of
Handles are the Windows equivalent to Posix descriptors. They are
references to a lot of different OS objects, like files, sockets,
semaphores, processes, threads, etc. They are *not* references to
memory regions. When you reserve memory the standard way, you only get
an address, not a handle.
However, handles are also potentially references to shared memory
objects, in Windows terminology called "file mappings"(*), and thus they
are created when you call mmap() in Cygwin. mmap() OTOH is called by
malloc() *iff* the malloc request is > 256K.
Those of you most familiar with the Windows environment could perhaps help
here. Is this a bug in Cygwin memory management?
We never can be sure it's not a bug in the DLL, but if a simple loop
like this would fail all the time, we would probably have more serious
problems.
I will be happy to provide additional information as soon as I know what is
pertinent.
I tested the test application with g77 and it runs fine. Memory usage,
VM size, and handle count are constant in every loop. No memory leak,
no handle leak. It might be a bug in the fortran lib, after all. I'm
not a fortran expert so I don't know what happens under the hood of the
write() call. If you can break down the test application and especially
the write() call into plain C, it might be quite instructive.
Corinna
(*) To emulate mmap() you have to do two calls in Windows:
HANDLE map_handle = CreateFileMapping (file_handle, ...);
void *address = MapViewOfFile(map_handle, ....);
So you have a handle to the "file mapping" and an arbitrary number
of addresses to "views".