Fork problem with hexchat if cygserver is running

Fork problem with hexchat if cygserver is running

[Ken Brown]

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain; charset="utf-8", Size: 2180 bytes --]

Roughly 1 out of 3 times that I try to use hexchat, I get a fork failure:

31143510 [main] hexchat 12392 dofork: child 12399 - died waiting for dll 
loading, errno 11

It only happens if cygserver is running.  I caught it under strace and saw the 
following:

    29   25558 [main] hexchat 12399 frok::child: hParent 0xAF0, load_dlls 1
    43   25601 [main] hexchat 12399 open_shared: name cygpid.12392, n 12392, 
shared 0x1100000 (wanted 0x0), h 0x10C, *m 6
    35   25636 [main] hexchat 12399 getpid: 12399 = getpid()
    65   25701 [main] hexchat 12399 transport_layer_pipes::connect: Try to 
connect to named pipe: \\.\pipe\cygwin-e022582115c10879-lpc
   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.

Here are the reproduction instructions:

1. Start the cygserver service.

2. Start the X server.  (I do this by using the XWin Server shortcut, which 
basically just calls startxwin.)

3. Start xterm, and run 'hexchat &'.

4. Select the freenode network and click Connect.

Roughly 1 out of 3 times, the dofork error will print in the xterm window, and 
hexchat will hang at "Looking up chat.freenode.net".

Ken

P.S. File this under "No good deed goes unpunished."  I was trying to use 
hexchat to join #cygwin-developers.  I can still do that on 2 out of 3 attempts, 
but now I'm sidetracked trying to do a bisection.
\x03B‹KCB”\x1c›Ø›\x19[H\x1c™\^[ܝ\x1cΈ\b\b\b\b\b\b\x1a\x1d\x1d\x1c\x0e‹ËØÞYÝÚ[‹˜ÛÛKÜ\x1c›Ø›\x19[\Ëš\x1d^[[\x03B‘TNˆ\b\b\b\b\b\b\b\b\b\b\b\b\b\b\b\b\b\b\x1a\x1d\x1d\x1c\x0e‹ËØÞYÝÚ[‹˜ÛÛKÙ˜\KÃB‘^[ØÝ[Y[\x18]\x1a[ÛŽˆ\b\b\b\b\b\b\b\b\x1a\x1d\x1d\x1c\x0e‹ËØÞYÝÚ[‹˜ÛÛKÙ^[ØÜËš\x1d^[[\x03B•[œÝXœØÜšX™H\x1a[™›Îˆ\b\b\b\b\b\x1a\x1d\x1d\x1c\x0e‹ËØÞYÝÚ[‹˜ÛÛKÛ[\vÈÝ[œÝXœØÜšX™K\Ú[\^[\x19CBƒB

Re: Fork problem with hexchat if cygserver is running

[Achim Gratz]

Ken Brown writes:
> P.S. File this under "No good deed goes unpunished."  I was trying to use 
> hexchat to join #cygwin-developers.  I can still do that on 2 out of 3 attempts, 
> but now I'm sidetracked trying to do a bisection.

FYI: I connect using znc (running on a rasPi) via erc from Emacs.


Regards,
Achim.
-- 
+<[Q+ Matrix-12 WAVE#46+305 Neuron microQkb Andromeda XTk Blofeld]>+

SD adaptations for KORG EX-800 and Poly-800MkII V0.9:
http://Synth.Stromeko.net/Downloads.html#KorgSDada

--
Problem reports:       http://cygwin.com/problems.html
FAQ:                   http://cygwin.com/faq/
Documentation:         http://cygwin.com/docs.html
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple

Re: Fork problem with hexchat if cygserver is running

[Michael Haubenwallner]

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:
> 
> 31143510 [main] hexchat 12392 dofork: child 12399 - died waiting for dll 
> loading, errno 11
> 
> It only happens if cygserver is running.  I caught it under strace and saw the 
> following:
> 
>     29   25558 [main] hexchat 12399 frok::child: hParent 0xAF0, load_dlls 1
>     43   25601 [main] hexchat 12399 open_shared: name cygpid.12392, n 12392, 
> shared 0x1100000 (wanted 0x0), h 0x10C, *m 6
>     35   25636 [main] hexchat 12399 getpid: 12399 = getpid()
>     65   25701 [main] hexchat 12399 transport_layer_pipes::connect: Try to 
> connect to named pipe: \\.\pipe\cygwin-e022582115c10879-lpc
>    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.

/haubi/

--
Problem reports:       http://cygwin.com/problems.html
FAQ:                   http://cygwin.com/faq/
Documentation:         http://cygwin.com/docs.html
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple

Re: Fork problem with hexchat if cygserver is running

[Corinna Vinschen]

[-- Attachment #1: Type: text/plain, Size: 2430 bytes --]

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

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]

Re: Fork problem with hexchat if cygserver is running

[Corinna Vinschen]

[-- Attachment #1: Type: text/plain, Size: 2739 bytes --]

On Aug  8 10:24, Corinna Vinschen wrote:
> 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?

I've sent a preliminary (untested) patch to the cygwin-patches ML.
Can you two please review it?

Ken, can you also test it in your scenario, please?


Thanks,
Corinna

-- 
Corinna Vinschen
Cygwin Maintainer

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]