[PATCH RFC] fork: reduce chances for "address space is already occupied" errors
Corinna Vinschen
corinna-cygwin@cygwin.com
Thu Mar 28 12:37:00 GMT 2019
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).
>
> >
> > 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?
https://sourceware.org/ml/cygwin-patches/2019-q1/msg00061.html
Corinna
--
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/681813c4/attachment.sig>
More information about the Cygwin-patches
mailing list