Mailing-List: contact cygwin-help@cygwin.com; run by ezmlm List-Subscribe: List-Archive: List-Post: List-Help: , Sender: cygwin-owner@cygwin.com Mail-Followup-To: cygwin@cygwin.com Delivered-To: mailing list cygwin@cygwin.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" To: , 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/