This is the mail archive of the
mailing list for the Cygwin project.
RE: Cygwin Shell Fails to Start when Enabling High Address
- From: Benjamin Cao <becao at progress dot com>
- To: "cygwin at cygwin dot com" <cygwin at cygwin dot com>
- Date: Mon, 27 Jul 2015 18:41:30 +0000
- Subject: RE: Cygwin Shell Fails to Start when Enabling High Address
- Authentication-results: sourceware.org; auth=none
- References: <a0044cbe3ab747048d7246806562f509 at ntmaexbe03 dot bedford dot progress dot com> <20150224213422 dot GS437 at calimero dot vinschen dot de>
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?
From: firstname.lastname@example.org [mailto:email@example.com] On Behalf Of Corinna Vinschen
Sent: Tuesday, February 24, 2015 4:34 PM
Subject: Re: Cygwin Shell Fails to Start when Enabling High Address
On Feb 24 19:58, Benjamin Cao wrote:
> 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.
(*) 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