X-Recipient:	archive-cygwin AT delorie DOT com
DomainKey-Signature:	a=rsa-sha1; c=nofws; d=sourceware.org; h=list-id
	:list-unsubscribe:list-subscribe:list-archive:list-post
	:list-help:sender:from:to:subject:date:message-id:references
	:in-reply-to:content-type:content-transfer-encoding
	:mime-version; q=dns; s=default; b=XpsSgRZ2nWVpJAbH1j4z0Av6HL6MI
	B2nUabCVykWxvahY3+AxC5Jo0rwMq/cc5hBdyAivkEzEQ8XYie7t+wJ1yt9xcH81
	VI/3yXP73nKE05wMtiDe0V8argsBfCN+u4LGubc1fg9FG52M5tLkeuMMSrkfSbLz
	ra37+6O5n0BaLg=
DKIM-Signature:	v=1; a=rsa-sha1; c=relaxed; d=sourceware.org; h=list-id
	:list-unsubscribe:list-subscribe:list-archive:list-post
	:list-help:sender:from:to:subject:date:message-id:references
	:in-reply-to:content-type:content-transfer-encoding
	:mime-version; s=default; bh=cdynfVsixn89nYM6AeRSOGgKXdc=; b=aaY
	MupS/QMhfLdeHx1rSnZkRdmMhxsTtHqhprb4dLuOkuP408E9YVHa/ad4FFW3JzBU
	cIdus2au+tN3+sKBIiUs6+MT2sKw55aCnl3ncQS+JXMNjFKf1w414WSo+pwsBxTF
	O+SginIgCQu44RP+6fxnR7MpBwZpCZNGz7F3nL/Y=
Mailing-List:	contact cygwin-help AT cygwin DOT com; run by ezmlm
List-Id:	<cygwin.cygwin.com>
List-Subscribe:	<mailto:cygwin-subscribe AT cygwin DOT com>
List-Archive:	<http://sourceware.org/ml/cygwin/>
List-Post:	<mailto:cygwin AT cygwin DOT com>
List-Help:	<mailto:cygwin-help AT cygwin DOT com>, <http://sourceware.org/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
Authentication-Results:	sourceware.org; auth=none
X-Virus-Found:	No
X-Spam-SWARE-Status:	No, score=4.1 required=5.0 tests=AWL,BAYES_50,CYGWIN_OWNER_BODY,MIME_BASE64_BLANKS,RCVD_IN_DNSWL_NONE,SPF_HELO_PASS,SPF_PASS autolearn=no version=3.3.2
X-HELO:	mail1.bemta12.messagelabs.com
X-Env-Sender:	becao AT progress DOT com
X-Msg-Ref:	server-15.tower-126.messagelabs.com!1438022498!21374809!1
X-StarScan-Received:
X-StarScan-Version:	6.13.16; banners=-,-,-
X-VirusChecked:	Checked
From:	Benjamin Cao <becao AT progress DOT com>
To:	"cygwin AT cygwin DOT com" <cygwin AT cygwin DOT com>
Subject:	RE: Cygwin Shell Fails to Start when Enabling High Address
Date:	Mon, 27 Jul 2015 18:41:30 +0000
Message-ID:	<56960a5bb2344de09875b4d117bf19b4@ntmaexbe03.bedford.progress.com>
References:	<a0044cbe3ab747048d7246806562f509 AT ntmaexbe03 DOT bedford DOT progress DOT com> <20150224213422 DOT GS437 AT calimero DOT vinschen DOT de>
In-Reply-To:	<20150224213422.GS437@calimero.vinschen.de>
x-ms-exchange-transport-fromentityheader:	Hosted
x-ems-proccessed:
x-ems-stamp:	KawmhX0/apbm9wesEEN6nQ==
MIME-Version:	1.0
X-IsSubscribed:	yes
X-MIME-Autoconverted:	from base64 to 8bit by delorie.com id t6RIfwaI031887

Hi,

We are revisiting our issue with running Cygwin by enabling the AllocationPreference registry to run in high address. We’re hoping some clarification from our colleague could help shed some light on our situation.

“A major part of the work we did in the NT64 port was making sure that 64-bit pointers are not truncated to 32 bits. Most of the time you can get away with a truncated pointer because the address is in the lower 4GB of the address space and the upper 32 bits of the 64-bit pointer are not used. The AllocationPreference=0x100000 setting forces memory allocations to use addresses above 4GB so that the upper 32 bits of 64-bit pointers are used. This can uncover bugs that would otherwise not be found until a process has used a lot of memory. Rather than stressing the machines by having every test allocate a ton of memory we can use this setting to accomplish the same thing. This testing has found several bugs in existing code and it helps guard against developers making the mistake of truncating pointers in new code.”

This is a setting supported by Microsoft (see below).
The AllocationPreference registry setting is documented on Microsoft’s website:   https://msdn.microsoft.com/en-us/library/windows/hardware/dn613975(v=vs.85).aspx

Usually, VirtualAlloc returns virtual addresses in low -> high order. So, unless your process allocates a lot of memory or it has a very fragmented virtual address space, it will never get back very high addresses. This is possibly hiding bugs related to high addresses. There is a simple way to force allocations in top -> down order in Windows Server 2003, Datacenter Edition and Enterprise Edition operating systems and this can reveal important bugs.

It’s important that we have this registry enabled for our work and if your answer is still the same as before, will getting a support contract enable us to get this capability?

Thanks,
Ben Cao

-----Original Message-----
From: cygwin-owner AT cygwin DOT com [mailto:cygwin-owner AT cygwin DOT com] On Behalf Of Corinna Vinschen
Sent: Tuesday, February 24, 2015 4:34 PM
To: cygwin AT cygwin DOT com
Subject: Re: Cygwin Shell Fails to Start when Enabling High Address

Hi Benjamin,

On Feb 24 19:58, Benjamin Cao wrote:
> Hi,
> 
> I had to enable high address for some machines for testing. I set the 
> AllocationPreference registry key to be 0X100000.

Cygwin doesn't support this AllocationPreference registry setting.

Cygwin and thus Cygwin applications(*) are already large address aware.
Cygwn uses large address regions automatically if available, but it's essential that Cygwin itself can decide how and what to use them for.

Cygwin will also use MEM_TOP_DOWN allocations in certain system calls (e.g. mmap) but this, too, is crafted to avoid collisions, and Cygwin needs full control over this behaviour.

In general, Cygwin needs as much control over memory allocations as possible in Windows for several reasons, mainly for the sake of fork and exec calls.

So, having said that, AllocationPreference 0x100000 breaks Cygwin's memory handling.  Therefore, don't use it in conjunction with Cygwin applications.


Corinna


(*) There are exceptions, of course.  32 bit applications using
    the high bit of addresses for dubious reasons exist.  Of course
    they deserve to be broken.

-- 
Corinna Vinschen                  Please, send mails regarding Cygwin to
Cygwin Maintainer                 cygwin AT cygwin DOT com
Red Hat

- Raw text -