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
Subject:	RE: Memory Management on AMD64 in 32-bit mode
Date:	Tue, 9 Dec 2003 12:55:55 -0500
Message-ID:	<3ED686A715B54646AF1BC06C2BFBA4A00165F390@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 17:55:55.0609 (UTC) FILETIME=[B195F490:01C3BE7D]
X-MIME-Autoconverted:	from quoted-printable to 8bit by delorie.com id hB9HvDQY003774

This looks like a logic error in fork.cc/dcrt0.cc to me, but I'm
probably not understanding something.

alloc_stack_hard_way assumes that the memory at ci->stacktop is
available. ci->stacktop is set to be the region of memory that contains
a stack variable in the parent process at the time that stack_base is
called.

alloc_stack_hard_way is called when the region containing the stack as
of the call to alloc_stack is at the same place as the region containing
the stack at the time that stack_base was called.

I don't exactly see how it is safe to assume that the child process will
have unused memory at the location that corresponds to the parent
process's stack region at the time that stack_base was called, but I've
only spent 1 hour on the problem. In any case, it isn't available.

A minor problem: %E always says Win32 error 0 even when GetLastError()
returns a non-zero value. In fact, VirtualAlloc is setting the last
error to what one would expect.

I assume that there's a very strong reason why this code can't just
allocate a stack any-old-place (calling VirtualAlloc with first arg 0)
and use it. What I don't understand is the nature of the constraints. If
the parent needs to know, why not have stack_base make a call to
VirtualAlloc with first arg 0 to allocate a brand-new region, on the
theory that such a region is a lot more likely to end up with a
corresponding hole in the child process?

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

- Raw text -