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

[Michael Haubenwallner <michael dot haubenwallner at ssi-schaefer dot com>]

Hi Corinna,

On 3/28/19 9:30 PM, Corinna Vinschen wrote:
> 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.

Please find attached the output of rebase -i for the dlls after bootstrap
on Cygwin 3.0.4, each built with ld from binutils-2.31.1.

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

Feels like I need some Cygwin rebase step in Gentoo Prefix anyway, as there
are ~250 dlls right after bootstrap - without any application yet.

Thanks!
/haubi/

Attachment: rebase-info.txt.xz
Description: application/xz