[PATCH RFC] fork: reduce chances for "address space is already occupied" errors
Michael Haubenwallner
michael.haubenwallner@ssi-schaefer.com
Thu Mar 28 11:48:00 GMT 2019
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).
>
> I'm not quite sure how to find out what happens, unless you stop the
> process in reserve_space and inspect the memory layout with sysinternal's
> vmmap tool:
>
> https://docs.microsoft.com/en-us/sysinternals/downloads/vmmap
Maybe I will try that one - thanks for the pointer!
Are you about to apply the patch?
Thanks!
/haubi/
More information about the Cygwin-patches
mailing list