Message-ID: <47819226.40300@tlinx.org>
Date: Sun, 06 Jan 2008 18:44:54 -0800
From: Linda Walsh <cygwin@tlinx.org>
User-Agent: Thunderbird 2.0.0.9 (Windows/20071031)
MIME-Version: 1.0
To: cygwin@cygwin.com
CC: wayne@4raccoons.com
Subject: Re: mmap failing
References: <47616D31.7090002@4raccoons.com> <20071213175934.GB25863@calimero.vinschen.de> <476185AF.5000906@4raccoons.com> <20071214111508.GD25863@calimero.vinschen.de> <20071214134147.GG25863@calimero.vinschen.de> <20071214135239.GJ25863@calimero.vinschen.de> <ba40711f0712140634u6c5d268fxfb49544d5b6927ba@mail.gmail.com> <20071214172454.GL25863@calimero.vinschen.de> <4762FCCD.6030804@4raccoons.com>
In-Reply-To: <4762FCCD.6030804@4raccoons.com>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit
Mailing-List: contact cygwin-help@cygwin.com; run by ezmlm
Sender: cygwin-owner@cygwin.com
Mail-Followup-To: cygwin@cygwin.com

  Wayne Christopher wrote:
> I have a 268MB file open for writing.  I close it and then
> immediately try to mmap() it, and a get ENOMEM.  However I do have the
> VM space available and can malloc() the size of the file right after the 
> failure.  Also, I have mmap()'ed other similar files in the same program 
> before this, but these had not just been closed.
> 
> Any suggestions for solutions or workarounds?  Maybe strategic use of 
> fsync() ?
----
	Don't know if this problem was 'solved' or not, but I'm guessing
that mmap attempts to allocate a large chunk of virtual memory to map the
file to (e.g. 268MB in your example).  The problem has to do with finding
268MB of contiguous address space -- and I believe that was the 'rub'. Over
time, the "free memory areas"(1) get fragmented and when large blocks of
memory are desired, you may get back a failure if Win cannot find a
block large enough to fit your request -- i.e. it may not be able to find
a single memory block large enough to satisfy your request.
So you get back an error.

	I'm not sure what you can use to solve this at the cygwin-application
level, but at the windows-application level Microsoft offers a something
called a 'low fragmentation heap' (LFH), that tries to lower fragmentation
for many applications.  According to http://support.microsoft.com/kb/929136,
it can be turned off 'accidentally' in some situations which can cause
more heap-fragmentation problems.  It's unlikely most users would
encounter this problem.

	Windows has more than one memory allocation pool that it uses
(main heap, for example instead of low-frag heap) and I would guess
more than one of them could get overly fragmented.  I'd think the
system would 'cleanup' at some point.  I've only encountered the
'out-of-mem' (when I had enough, but alloc size was too large) once
that I remember.  But I when I immediately retried the program,
the error had 'gone away'...

Linda

--
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/