Re: Windows heaps and Cygwin heap

[Corinna Vinschen <corinna-cygwin at cygwin dot com>]

On May 13 06:43, Ryan Johnson wrote:
> On 13/05/2011 4:36 AM, Corinna Vinschen wrote:
> >I'm going to squeeze my rambling in between this thread since
> >it's related.  I just changed the subject.
> >
> >On Apr 19 14:16, Ryan Johnson wrote:
> >>Regardless of file mapping behavior, though, I don't see right off
> >>how to make this problem go away. Nothing stops thread stacks or
> >>heaps from causing problems with other dlls, and they seem to move
> >>around even when they could have stayed put.
> >I noticed this as well on W7 32 bit.  Even the process default heap
> >(what's now called heap 0) is moved around wildly.
> >
> >There are noticable differences to Windows XP.  On XP, the address
> >ranges from 0x10000 to 0x230000 are neither heaps, nor is any part of
> >them shareable.
> >
> >More importantly, the heaps on XP are not so versatile.  In contrast to
> >W7, if I start the same application multiple times, the heaps are always
> >in the same spot.  Apparently some Windows DLLs create their own heaps.
> >The more Windows DLL are loaded in a process, the more heaps I see.  On
> >XP, all of them are always in the same place.  On W7 the heap addresses
> >are plain erratic.
> >
> >Short break for the commercials:  We can safely make the assumption that
> >the differences have been introduced with Windows Vista.  So, if I said
> >W7 it's actually NT 6.x, in contrast to the older NT 5.x kernels.  Ok,
> >back to the show.
> This is true, but I get the impression that W7, x64 in particular,
> "refines" the behavior in ways that make it even more hostile to
> fork than Vista. I could be wrong, tho.

I don't think it depends on x64, because Cygwin is a 32 bit processs so
the address space is restricted to the usual 2 Gigs anyway.  However,
as far as Vista is concerned, MSFT admitted certain flaws in the
implementation (for instance, by using RtlRandom instead of RtlRandomEx)
and so the W7 ASLR algorithm has been "improved".

> I'll try out the patch on my machine, since I seem to have an
> especially hostile environment for fork for some reason (it sure
> made testing my fork patches much easier than I would have liked...)
> 
> However, I've only seen failure to allocate the cygheap kill fork
> once or twice ever. It's statically-linked dlls that nearly always
> cause the problems.

Yes, but AFAICS the problem is practically always due to address
clashes in the < 0x20000000 area.  Heaps fight against heaps, 
stacks against stacks.  It's a bloddy mess.


Corinna

-- 
Corinna Vinschen                  Please, send mails regarding Cygwin to
Cygwin Project Co-Leader          cygwin AT cygwin DOT com
Red Hat