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
signature.asc
Description: PGP signature