[PATCH RFC] fork: reduce chances for "address space is already occupied" errors
Mon Apr 1 14:28:00 GMT 2019
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.
-------------- next part --------------
A non-text attachment was scrubbed...
Size: 3884 bytes
Desc: not available
More information about the Cygwin-patches