Fork problem with hexchat if cygserver is running
Thu Aug 8 07:27:00 GMT 2019
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
> 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.
Problem reports: http://cygwin.com/problems.html
Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
More information about the Cygwin