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

[Corinna Vinschen]

Hi Michael,

On Mar 27 09:26, Michael Haubenwallner wrote:
> Hi Corinna,
> 
> On 3/26/19 7:28 PM, Corinna Vinschen wrote:
> > On Mar 26 19:25, Corinna Vinschen wrote:
> >> Hi Michael,
> >>
> >>
> >> Redirected to cygwin-patches...
> >>
> >>
> >> On Mar 26 18:10, Michael Haubenwallner wrote:
> >>> Hi Corinna,
> >>>
> >>> as I do still encounter fork errors (address space needed by <dll> is
> >>> already occupied) with dynamically loaded dlls (but unrelated to
> >>> replaced dlls), one of them repeating even upon multiple retries,
> >>
> >> Why didn't rebase fix that?
> 
> As far as I understand, rebasing is about touching already installed
> dlls as well, which would require to restart all Cygwin processes.
> As the problem is about some dll built during a larger build job,
> this is not something that feels useful to me.

Wait, let me understand what's going on.  IIUC you're building DLLs
which are then used during the build job itself, right?

> > Btw., is that 32 or 64 bit?  Both?
> 
> I'm on 64bit only, can't say for 32bit.  And while in theory possible,
> I'm not after supporting 32bit Cygwin in Gento Prefix at all...

If so, then I'm really curious how many DLLs are affected and why this
occurs on 64 bit.

As you know, 64 bit has a defined memory layout.  Binutils ld is
supposed to base the DLLs to a pseudo-random address in the area between
0x4:00000000 and 0x6:00000000.  This area is occupied by un-rebased DLLs
only.  8 Gigs is a *lot* of space for DLLs.

That also means that the DLLs should not at all collide with windows
objects (typically reserved in the lesser 2 Gigs area), unless they
collide with themselves.  At least that's the idea.

Can you check what addresses the freshly built DLLs are based on by LD?
Is there a chance that the algorithm used in LD is too dumb?

Or, hmm.  Is there a chance that newer Windows loads dynamically loaded
DLLs whereever it likes, ignoring the base address, ASLR-like, even
if the DLL is marked as non-ASLR-aware?  But then again, we should have
a lot more complaints on the list...

> >>>  I'm
> >>> coming up with attached patch.
> >>>
> >>> What do you think about it?
> >>
> >> I'm not opposed to this patch but I don't quite follow the description.
> >> threadinterface->Init only creates three event objects.  From what I can
> >> tell, Events are stored in Paged and Nonpaged Pools, so they don't
> >> affect the processes VM.  What am I missing?
> 
> Honestly, I'm not completely sure whether this patch really does help:
> Beyond the Events, there also is CreateNamedPipe and CreateFile used
> in fhandler_pipe::create via sigproc_init, and these causing the address
> conflicts with some dll actually is nothing more than a wild guess:
> While their returned handles are below the conflicting dll address,
> who can tell what these API calls do allocate internally?

The handles are not addresses.  If the sigproc_init stuff collides,
I only see two chances for that, the process-local read/write buffers
of the signal pipe, and the stack of the read_sig thread.

If this patch helps your situation, we can pull it in and test it,
but I think your situation asks for more debugging along the lines
of the DLL rebasing above.


Thanks,
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/20190327/bfc8068b/attachment.sig>