Mailing-List: contact cygwin-help AT cygwin DOT com; run by ezmlm
List-Subscribe: <mailto:cygwin-subscribe AT cygwin DOT com>
List-Archive: <http://sources.redhat.com/ml/cygwin/>
List-Post: <mailto:cygwin AT cygwin DOT com>
List-Help: <mailto:cygwin-help AT cygwin DOT com>, <http://sources.redhat.com/ml/#faqs>
Sender: cygwin-owner AT cygwin DOT com
Delivered-To: mailing list cygwin AT cygwin DOT com
Date: Wed, 13 Mar 2002 09:11:22 +0100
From: Corinna Vinschen <cygwin AT cygwin DOT com>
To: cygwin AT cygwin DOT com
Subject: Re: mmap of large amount returns invalid pointer
Message-ID: <20020313091122.O29574@cygbert.vinschen.de>
Mail-Followup-To: cygwin AT cygwin DOT com
References: <BF35D9C143BCCC4EB63181B67C9320C83A9B75 AT serv-075 DOT icon-germany DOT local>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <BF35D9C143BCCC4EB63181B67C9320C83A9B75@serv-075.icon-germany.local>
User-Agent: Mutt/1.3.22.1i

On Tue, Mar 12, 2002 at 11:44:36PM +0100, Heribert Dahms wrote:
> Hi Stephen and Corinna,
> 
> looks like you have overlooked that mmap doesn't return NULL
> despite win32 error in strace (see below):
> 
> c:\>net helpmsg 1455
> 
> The paging file is too small for this operation to complete.

No, I didn't overlook it, it's exactly what I've been seeing on
my machine as well as I mentioned yesterday.

If you look into the strace you'll see that MapViewOfFileEx()
returns a valid memory area.  And no, it does *not* return an
error code.  MapViewOfFileEx() is reliable enough to not return
a memory area and an error code.
The failing function is a following VirtualProtect() which job
is to set the memory protection on the allocated memory area
correctly.  And that's actually surprising.  VirtualProtect()
shouldn't have problems with memory since it doesn't allocate
any.  At least it shouldn't.
But the real problem is that the page file is, well, full after
the mmap() call.  A following printf is trying to allocate a
small amount of memory but allocation fails apparently and at
one point a check for a failed malloc() is missing.
So the SEGV is actually a followup of the fact that there isn't
any memory left to allocate.

> Second, (may mean nothing) why is h:188 first and h:190 second time?

Means nothing.

Corinna

-- 
Corinna Vinschen                  Please, send mails regarding Cygwin to
Cygwin Developer                                mailto:cygwin AT cygwin DOT com
Red Hat, Inc.

--
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple
Bug reporting:         http://cygwin.com/bugs.html
Documentation:         http://cygwin.com/docs.html
FAQ:                   http://cygwin.com/faq/