This is the mail archive of the cygwin mailing list for the Cygwin project.

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: Memory leak problem reported with gfortran

Corinna Vinschen wrote:
On Feb 3 11:24, Jerry DeLisle wrote:
I have confirmed this problem on Cygwin reported here:

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.


(*) 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".


The test also appears very clean on Linux. The gfortran library is implemented in C. I need to examine some dumps from the compiler and I will get back with you off list if I don't spot the problem. I am fairly certain we have an ambiguity in the gfortran library at this point.

The test is not doing file I/O. We are WRITEing to a 10000 byte internal string that has to be allocated in memory.


Unsubscribe info:
Problem reports:

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]