Fork problem with hexchat if cygserver is running

[Corinna Vinschen]

On Aug  8 09:27, Michael Haubenwallner wrote:
> On 8/7/19 7:41 PM, Ken Brown wrote:
> > Roughly 1 out of 3 times that I try to use hexchat, I get a fork failure:
> > [...]
> >    363   26064 [main] hexchat 12399 C:\cygwin64\bin\hexchat.exe: *** fatal error 
> > in forked process - fixup_shms_after_fork: NtMapViewOfSection (0x7FF4EE130000), 
> > status 0xC0000018.  Terminating.
> > 
> > [status 0xC0000018 is STATUS_CONFLICTING_ADDRESSES.]
> > 
> > This was under cygwin-3.0.7-1.  It also happens with cygwin1.dll
> > built from the current master branch, and it also happens with
> > cygwin-3.0.6-1.  Not being familiar with this part of the Cygwin
> > code, my first thought was to do a bisection.  But I haven't yet
> > found a good revision to start with.  I will still try to do that,
> > but in the meantime I thought I should report it.
> 
> I doubt there is a commit that introduces this problem.  Instead, this feels
> like an address conflict with some (internal) memory allocated for some Windows
> (or even Cygwin) object.
> So I'd wonder if early memory reservation like is done for dynamically loaded
> DLLs may help for SHMs as well.

That sounds like a good idea for a start, but I don't think so.  The
interesting thing here is not that it fails, but that it fails with the
above address:

  NtMapViewOfSection (0x7FF4EE130000)
                      ^^^^^^^^^^^^^^

Note that this address is a 48 bit address, starting with 0x7f.

Up to the current Cygwin 3.0.7, Cygwin's mmap only uses 44 bit addresses
below 0x0700:00000000, top-down.  The reason is that older 64 bit
Windows versions only support a 44 bit address space.  Starting with
Windows 8.1, Windows supports a 48 bit address space, and Cygwin 3.1
will support that as well, by utilizing the address space top-down
from 0x7000:00000000.

However, the above address is beyond even that, in the middle of the
address space utilized by Windows itself.  Combine that with ASLR...

Given that, my guess is that we're actually running into the
problem that the shmat() call does not utilize the mmap address
allocator, so the chosen address has a high probability to collide
with Windows' own stuff.

IMHO, the fix would be to make the mmap_alloc object global, so it
can be utilized by shmat() to create more sane addresses.

Does that make sense?


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/attachments/20190808/d32ea422/attachment.sig>