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
signature.asc
Description: PGP signature
