Memory leak problem reported with gfortran
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
>> I will be happy to provide additional information as soon as I know what is
> 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: http://cygwin.com/ml/#unsubscribe-simple
Problem reports: http://cygwin.com/problems.html
More information about the Cygwin