This is the mail archive of the cygwin-patches mailing list for the Cygwin project.
Index Nav: | [Date Index] [Subject Index] [Author Index] [Thread Index] | |
---|---|---|
Message Nav: | [Date Prev] [Date Next] | [Thread Prev] [Thread Next] |
Other format: | [Raw text] |
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
Attachment:
signature.asc
Description: PGP signature
Index Nav: | [Date Index] [Subject Index] [Author Index] [Thread Index] | |
---|---|---|
Message Nav: | [Date Prev] [Date Next] | [Thread Prev] [Thread Next] |