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
Mail-Followup-To: cygwin AT cygwin DOT com
Delivered-To: mailing list cygwin AT cygwin DOT com
X-MimeOLE: Produced By Microsoft Exchange V6.0.6487.1
content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain;
	charset="us-ascii"
Subject: RE: Memory Management on AMD64 in 32-bit mode
Date: Tue, 9 Dec 2003 06:57:49 -0500
Message-ID: <3ED686A715B54646AF1BC06C2BFBA4A00167A396@kita.basistech.com>
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
From: "Benson Margulies" <bim2003 AT basistech DOT com>
To: <jurgen DOT defurne AT philips DOT com>, <cygwin AT cygwin DOT com>
X-OriginalArrivalTime: 09 Dec 2003 11:57:49.0678 (UTC) FILETIME=[AAF910E0:01C3BE4B]
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by delorie.com id hB9H2aU8017342

The error message rather unambiguously indicates that VirtualAlloc is
returning 0 with GetLastError() == 0. The call in question calls
VirtualAlloc with parameters derived from a call to VirtualQuery against
some stack storage. It seems that this version of Windows is not
altogether pleased to see a call to VA against already reserved storage.
It is also not altogether displeased.

Can someone explain the design of the path of code in stack allocation
that calls VQ and then runs around and calls VA?

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