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:to:from:subject:date:message-id:references :mime-version:content-type:content-transfer-encoding; q=dns; s= default; b=dIXO4HEZk1q1TZ7IjLyrAHhSku0qqq6xH/fpPOE+3tMsKlA3xTbeK zHzrleYroxxFCU3nXJDzg52BNjt8nO13t16b2nukc+G+2Mv7ie8KwB5cpHducXq6 wTrMZY2FS8rlJEgx/i4St6+EU6yvdM0h1/k0rokkRHmg4YIW722+yc= 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:to:from:subject:date:message-id:references :mime-version:content-type:content-transfer-encoding; s=default; bh=x/7PAIYQO+C3dtjvM/8Y/qtekKk=; b=MrOhaJSXTY+4dNPyg4PnuU/vt5aO lXDMhPfoLK2KvK0Q4HGC5zcgR/Qan1bxTipnBja7+li7mSGEoECpEkxQ67Vo8hxq UH2hOyImVGX6+CTgEj+AWhDNoVMlmn+c/dmfkLwMgtyJsvBvlt4ez1HpuCWJ4tR5 rscDa0Z3+zvyf3Y= 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=0.1 required=5.0 tests=AWL,BAYES_00,FSL_HELO_BARE_IP_2,RCVD_IN_DNSWL_LOW,RCVD_NUMERIC_HELO,RP_MATCHES_RCVD,SPF_HELO_PASS,SPF_PASS autolearn=no version=3.3.2 spammy=octave, Hx-languages-length:1739, Octave, 4gb X-HELO: plane.gmane.org To: cygwin AT cygwin DOT com From: Achim Gratz Subject: Re: Process map and fork problems Date: Wed, 20 Apr 2016 11:01:07 +0000 (UTC) Lines: 42 Message-ID: References: <20160420104633 DOT GA26118 AT calimero DOT vinschen DOT de> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit User-Agent: Loom/3.14 (http://gmane.org/) X-IsSubscribed: yes Corinna Vinschen cygwin.com> writes: > This is one heap. The first region is just the already committed > part, the remainder is the reserved part. > > THis is the standard Cygwin heap area on 32 bit machines, which always > starts at 0x20000000. So, shouldn't rebase keep this area clear on these machines? > On 64 bit systems, 32 bit applications have a 4 Gig virtual address > space. On 32 bit systems, procecces only have a 2 Gig virtual address > space, unless the /3gb kernel option is given. OK. On Windows7 that means 'BCDedit /set increaseuserva=3072', right? I think all the affected machines have 4GB memory installed, but the option may not have been default when they were installed. > On 64 bit systems and on /3gb enabled 32 bit systems, the heap of 32 bit > Cygwin processes always starts at 0x80000000L. > > Since that isn't available on 32 bit systems by default, the heap has > to start within the lower 2 Gigs. That's where the 0x2000000 address > comes from. With /3GB you mean 4GT (aka PAE), right? And 32bit is without PAE? > If you have collisions because you're providing too many Cygwin DLLs, > you have to tweak these installations manually. As long as Cygwin determines automatically where the heap is located, then rebase should take care of that. It already knows to skip the cygwin1.dll address range, how would it ask for the heap location? No I don't think I have an overly large Cygwin installation, but Perl, Octave and Python pull in a lot of images. I guess what pushed it over the edge is the LLVM stuff that something pulls in since a few months, so that explains the timeframe of the problem popping up most probably. Regards, Achim. -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple