This is the mail archive of the
cygwin-patches
mailing list for the Cygwin project.
Re: Extend faq.using to discuss fork failures
- From: Corinna Vinschen <corinna-cygwin at cygwin dot com>
- To: cygwin-patches at cygwin dot com
- Date: Thu, 3 Nov 2011 18:17:48 +0100
- Subject: Re: Extend faq.using to discuss fork failures
- References: <4E570031.4080800@cs.utoronto.ca> <20110830090020.GE30452@calimero.vinschen.de> <4E5CE899.4030605@cs.utoronto.ca> <4EB2C2CD.1080400@dronecode.org.uk>
- Reply-to: cygwin-patches at cygwin dot com
Hi Jon,
On Nov 3 16:35, Jon TURNEY wrote:
> On 30/08/2011 14:41, Ryan Johnson wrote:
> >That sounds reasonable, though I suspect we'd want want to keep the concluding
> >bits in the FAQ as well. Unfortunately, summertime free time has come to an
> >end so I don't know when I'll get to this next. Perhaps a good compromise for
> >now would be for you to post only the first FAQ question? That would at least
> >cut traffic to the cygwin ML a bit.
>
> I've updated Ryan's patch to hopefully address the comments made,
> polished the language a bit in places, and split it into a patch for
> the FAQ which just says how to fix problems and a patch for the UG
> which contains the technical details.
Thanks for doing that. I looks good to me, with just one exception.
> +<listitem>Address space layout randomization (ASLR). Starting with
> +Vista, Windows implements ASLR, which means that thread stacks,
> +heap, memory-mapped files, and statically-linked dlls are placed
> +at different (random) locations in each process. This behaviour
> +interferes with a proper <literal>fork</literal>, and if an
> +unmovable object (process heap or system dll) ends up at the wrong
> +location, Cygwin can do nothing to compensate (though it will
> +retry a few times automatically). In a 64-bit system, marking
> +executables as large address-ware and rebasing dlls to high
> +addresses has been reported to help, as ASLR affects only the
> +lower 2GB of address space.</listitem>
Starting with "In a 64-bit system" it's getting a bit weird:
- Starting with 4.5.3, gcc marks executables as large address aware
automatically, so this is going to be a lesser problem over time. Is
it worth to mention this at all? I suppose so, but the user should be
pointed to peflags to tests for this property first for the given
reason.
- Starting with Cygwin 1.7.10, the high address area will be used for
the application heap on 64 bit systems and large address aware
executables. Mmaps are located there, too. This in turn leaves more
room for DLLs in the normal 2 Gigs memory area. Therefore I would not
like to suggest rebasing DLLs into the high address area at all. This
should only be done by people who know what they are doing. Usually
there should be enough space in the lower 2 Gigs, especially when heap
and mmaps are out of the way, and given that the more recent rebaseall
will not create an arbitrary 64K hole between DLLs anymore when
rebasing.
With these changes, feel free to check in the patch.
Thanks,
Corinna
--
Corinna Vinschen Please, send mails regarding Cygwin to
Cygwin Project Co-Leader cygwin AT cygwin DOT com
Red Hat