Memory leak problem reported with gfortran

Jerry DeLisle
Mon Feb 4 21:25:00 GMT 2008

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.
> 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".

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:

More information about the Cygwin mailing list