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: List-Subscribe: List-Archive: List-Post: List-Help: , 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 To: "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: <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== Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 X-IsSubscribed: yes Content-Transfer-Encoding: 8bit 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