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:date:from:to:subject:message-id:reply-to
	:references:mime-version:content-type:in-reply-to; q=dns; s=
	default; b=eUAaxJ6Zh252PiaLWUFMwQ1b/3PCtjuQqwHa3qXFcP1UL6TA1b8Dk
	Ez4wtTuvN/Yq4DJ86w3nEm6YiD/1R7lX7tNAtDITDvqOUtFyqXk02Hl+Y8v2PlRt
	iXSoDwr1YceIwYX8IYcH9XxbAVSlvfmeP/czS4Q1DKVZBEcuAngQHA=
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:date:from:to:subject:message-id:reply-to
	:references:mime-version:content-type:in-reply-to; s=default;
	bh=u6uewDrCmzRHwI6mEPg7/i1N2JE=; b=yDF3OR8CdzQufkcgOokTFm9M7LDX
	gybrSevMGI5f7eTTOFlDsZrVn1Rb0c1UBa0/MAs5L3VwvS1IuP946d5+xRTLbVaI
	WCvZikaJFXN3q+JC3xrqp4DqV3YL7H7QOrpw21wxupuQAwIjgY2h/erZueRL1ctc
	75B2lYts+McVAmA=
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,KAM_LAZY_DOMAIN_SECURITY autolearn=no version=3.3.2
X-HELO:	calimero.vinschen.de
Date:	Mon, 27 Jul 2015 22:15:19 +0200
From:	Corinna Vinschen <corinna-cygwin AT cygwin DOT com>
To:	cygwin AT cygwin DOT com
Subject:	Re: Cygwin Shell Fails to Start when Enabling High Address
Message-ID:	<20150727201519.GB12449@calimero.vinschen.de>
Reply-To:	cygwin AT cygwin DOT com
Mail-Followup-To:	cygwin AT cygwin DOT com
References:	<a0044cbe3ab747048d7246806562f509 AT ntmaexbe03 DOT bedford DOT progress DOT com> <20150224213422 DOT GS437 AT calimero DOT vinschen DOT de> <56960a5bb2344de09875b4d117bf19b4 AT ntmaexbe03 DOT bedford DOT progress DOT com>
MIME-Version:	1.0
In-Reply-To:	<56960a5bb2344de09875b4d117bf19b4@ntmaexbe03.bedford.progress.com>
User-Agent:	Mutt/1.5.23 (2014-03-12)

--IiVenqGWf+H9Y6IX
Content-Type: text/plain; charset=utf-8
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable

On Jul 27 18:41, Benjamin Cao wrote:
> Hi,
>=20
> We are revisiting our issue with running Cygwin by enabling the
> AllocationPreference registry to run in high address. We=E2=80=99re hoping
> some clarification from our colleague could help shed some light on
> our situation.
>=20
> =E2=80=9CA 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=3D0x100000 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.=E2=80=
=9D
>=20
> This is a setting supported by Microsoft (see below).
> The AllocationPreference registry setting is documented on Microsoft=E2=
=80=99s website:   https://msdn.microsoft.com/en-us/library/windows/hardwar=
e/dn613975(v=3Dvs.85).aspx
>=20
> 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.
>=20
> It=E2=80=99s important that we have this registry enabled for our work an=
d if
> your answer is still the same as before, will getting a support
> contract enable us to get this capability?

So you're talking about a 64 bit application?  You didn't say so in your
OP.

Anyway, I'm very much puzzled.

Either your application is a native Windows, non-Cygwin application
using VirtualAlloc.  Then it doesn't matter how Cygwin handles memory
for it's own processes to you since the memory allocations in your
process have nothing to do with Cygwin's allocation style.

Or it's a POSIX application ported to Cygwin.  In this case you
shouldn't use VirtualAlloc but malloc or mmap, and the way memory gets
allocated is not in your realm, but in Cygwin's.  Also, on 64 bit Cygwin
all memory (except thread stacks) is allocated beyond 0x1:0000000
anyway.  On 32 bit with 3gb/4gt setting or on WOW64, the heap used for
malloc allocations < 256K is beyond 0x80000000 and mmap s are allocated
top down, so they start beyond 0x80000000 as well.
So a Cygwin application is either high memory clean or it will crash.


Corinna

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

--IiVenqGWf+H9Y6IX
Content-Type: application/pgp-signature

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2

iQIcBAEBCAAGBQJVtpFXAAoJEPU2Bp2uRE+gdYkP/iuLqn0k6kPAZ54aMMjGVjJb
FCUEzY28z+lagPxQOePWupBobvpICco/+1huajVehJdIgYPga/HKPzqNeAmS4pxo
WVQS63YVK5dZ1WdVfihuE4y+ui/bKVfIVu/s/D2G98jzMKPBB12TWl+NfUNxleoh
eWGkPoyWzpObSo1zl8O9ZzQore8Q/WS4NxRUsVEA3ktajC5lcyYNdLbrvbrBQkrq
6KRtXAmMN6IFBckJHBG6nu3tpB1hk5C3vJ3LmDfPPE/Gz4nV+QSfClDF+Cfj+vsK
PAxr0TVTQnLvpsWTd84j92KZDPnNQgVUZ3P6s7mhrYnMrnCarZxP9TdFEM4JS3Zt
jVDwfdJF6X0SEzXX5ZDL3J0Dry+KT4iOZ79ly/0HZKA8yQc0LuiioV6RyFez7kjJ
hhLLgpzuzyB5CGb6xQhq1HgQvMjNPGB09sJ9aGbVpO5jisB7THQXOCLzZvs1fc19
micWiaf+3gmQ4qEjbQfnx2+4EjfgFsJsVYuBecEdQ9wKelIG3zL5gQKR8ZVuN9y4
s15Mj2KyW8ta1IeArn5BVBQkBZhAJu0iWku42yeaZ8ODZu+kiIQ48L8mVDrg4U4H
Dg3afLk2vRqgI9okaC07EtuUcDpluZl5dxYIBDeMw2oJQqmDp32NJ19fmKV17uPX
9TBOFHDBcAGjmBWNbBJh
=Fcda
-----END PGP SIGNATURE-----

--IiVenqGWf+H9Y6IX--

- Raw text -