[PATCH RFC] fork: reduce chances for "address space is already occupied" errors

[Corinna Vinschen]

Michael,

On Mar 28 12:48, Michael Haubenwallner wrote:
> On 3/28/19 10:58 AM, Corinna Vinschen wrote:
> > On Mar 28 10:17, Michael Haubenwallner wrote:
> >> As it is not some other dll being loaded at the colliding adress: any
> >> idea how to find out _what_ is allocated there (in the forked child),
> >> to find out whether we can reserve these areas even more early?
> > 
> > I'm not sure what addresses you're talking about ATM.  The addresses in
> > the 0x4:00000000 - 0x6:00000000 range?
> 
> No, I'm thinking about the lower address that collides after relocation,
> if there is some cygwin allocated object we may allocate later...
> 
> > These are the interesting ones.
> > The relocation to some random low address should only occur if there's
> > a collision in this range.
> 
> This should be easier to find out (by inspecting the loaded dlls).

can you please collect the base addresses of all DLLs generated during
the build, plus their size and make a sorted list?  It would be
interesting to know if the hash algorithm in ld is actually as bad
as I conjecture.

If we can improve on the distribution within the 8 Gigs area by changing
ld's address generation(*), we may improve situations like these without
too much hassle.  As always, not a foolproof way out, but heck, 8 Gigs
is a lot of space for a couple 100 DLLs.


Corinna

(*) Maybe even a RNG is better than a hash here...

-- 
Corinna Vinschen
Cygwin Maintainer
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: not available
URL: <http://cygwin.com/pipermail/cygwin-patches/attachments/20190328/ac55d15f/attachment.sig>