This is the mail archive of the cygwin-developers mailing list for the Cygwin project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: Windows heaps and Cygwin heap


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'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.

Ryan



Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]