delorie.com/archives/browse.cgi | search |
X-Recipient: | archive-cygwin AT delorie DOT com |
X-Spam-Check-By: | sourceware.org |
Date: | Mon, 23 Apr 2012 18:49:30 +0200 |
From: | Corinna Vinschen <corinna-cygwin AT cygwin DOT com> |
To: | cygwin AT cygwin DOT com |
Subject: | Re: Two probable basing issues causing fork failures: (1) cygreadline7.dll has ASLR enabled, (2) default base address conflicts with ASLR-relocated/system DLLs |
Message-ID: | <20120423164930.GB25385@calimero.vinschen.de> |
Reply-To: | cygwin AT cygwin DOT com |
Mail-Followup-To: | cygwin AT cygwin DOT com |
References: | <00f201cd1f1d$43430230$c9c90690$@motionview3d.com> <20120420205019 DOT GA25994 AT ednor DOT casa DOT cgf DOT cx> <012001cd215c$b521ee20$1f65ca60$@motionview3d.com> <20120423145106 DOT GH7097 AT calimero DOT vinschen DOT de> <012801cd216e$8c447bf0$a4cd73d0$@motionview3d.com> |
MIME-Version: | 1.0 |
In-Reply-To: | <012801cd216e$8c447bf0$a4cd73d0$@motionview3d.com> |
User-Agent: | Mutt/1.5.21 (2010-09-15) |
Mailing-List: | contact cygwin-help AT cygwin DOT com; run by ezmlm |
List-Id: | <cygwin.cygwin.com> |
List-Unsubscribe: | <mailto:cygwin-unsubscribe-archive-cygwin=delorie DOT com AT cygwin DOT 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 |
On Apr 23 16:31, James Johnston wrote: > > As for the address space, we should stick to using the addresses below > > 0x70000000, top-down. The reason is that we also need room for the > > application heap. On 32 bit systems the heap will be placed at 0x20000000 > > and in case it's too small it will be extended up to the start > > address of the Cygwin DLL (minus 3 * 64K). > [...] > But on systems with ASLR, I noticed multiple ASLR system DLLs in this > address range. Even on clean Windows XP SP3 installations there was a > system DLL in the 0x60000000 - 0x70000000 range. Isn't it just by > luck that the DLLs didn't conflict and cause one to be relocated? (Or > does Cygwin rebasing have some more smarts I am overlooking, like > working around system DLLs that are already loaded? Although, that > wouldn't help with ASLR DLLs... it still sounds risky. And Windows > Update will potentially change the DLLs, too.) We have to compromise. There is no 100% guarantee that it works. > Certainly heap space is a compromise - I thought of that - but I would > guess most Cygwin users don't need it. At least, this one doesn’t! You don't know if you need it or not. It's something the application requests automatically under the hood (sbrk call). Corinna -- Corinna Vinschen Please, send mails regarding Cygwin to Cygwin Project Co-Leader cygwin AT cygwin DOT com Red Hat -- 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
webmaster | delorie software privacy |
Copyright © 2019 by DJ Delorie | Updated Jul 2019 |