X-Recipient: archive-cygwin AT delorie DOT com
X-Spam-Check-By: sourceware.org
Date: Mon, 04 Feb 2008 13:25:27 -0800
From: Jerry DeLisle <jvdelisle AT verizon DOT net>
Subject: Re: Memory leak problem reported with gfortran
In-reply-to: <20080204103512.GA5866@calimero.vinschen.de>
To: cygwin AT cygwin DOT com
Cc: Fortran List <fortran AT gcc DOT gnu DOT org>
Message-id: <47A782C7.3060501@verizon.net>
MIME-version: 1.0
Content-type: text/plain; charset=ISO-8859-1; format=flowed
Content-transfer-encoding: 7bit
References: <47A614EC DOT 1010104 AT verizon DOT net>  <20080204103512 DOT GA5866 AT calimero DOT vinschen DOT de>
User-Agent: Thunderbird 2.0.0.9 (X11/20071115)
X-IsSubscribed: yes
Mailing-List: contact cygwin-help AT cygwin DOT com; run by ezmlm
Precedence: bulk
List-Id: <cygwin.cygwin.com>
List-Unsubscribe: <mailto:cygwin-unsubscribe-archive-cygwin=delorie DOT com AT cygwin DOT com>
List-Subscribe: <mailto:cygwin-subscribe AT cygwin DOT com>
List-Archive: <http://sourceware.org/ml/cygwin/>
List-Post: <mailto:cygwin AT cygwin DOT com>
List-Help: <mailto:cygwin-help AT cygwin DOT com>, <http://sourceware.org/ml/#faqs>
Sender: cygwin-owner AT cygwin DOT com
Mail-Followup-To: cygwin AT cygwin DOT com
Delivered-To: mailing list cygwin AT cygwin DOT com

Corinna Vinschen wrote:
> 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".
> 
Corinna,

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.

Jerry



--
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple
Problem reports:       http://cygwin.com/problems.html
Documentation:         http://cygwin.com/docs.html
FAQ:                   http://cygwin.com/faq/