From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 96553 invoked by alias); 8 Aug 2019 08:57:43 -0000 Mailing-List: contact cygwin-help@cygwin.com; run by ezmlm Precedence: bulk List-Id: List-Subscribe: List-Archive: List-Post: List-Help: , Sender: cygwin-owner@cygwin.com Mail-Followup-To: cygwin@cygwin.com Received: (qmail 96546 invoked by uid 89); 8 Aug 2019 08:57:42 -0000 Authentication-Results: sourceware.org; auth=none X-Spam-SWARE-Status: No, score=-103.2 required=5.0 tests=AWL,BAYES_00,GOOD_FROM_CORINNA_CYGWIN,RCVD_IN_DNSWL_NONE autolearn=ham version=3.3.1 spammy= X-HELO: mout.kundenserver.de Received: from mout.kundenserver.de (HELO mout.kundenserver.de) (212.227.17.24) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Thu, 08 Aug 2019 08:57:41 +0000 Received: from calimero.vinschen.de ([24.134.7.25]) by mrelayeu.kundenserver.de (mreue107 [212.227.15.183]) with ESMTPSA (Nemesis) id 1M890H-1hzEjc3hxr-005JXA; Thu, 08 Aug 2019 10:57:35 +0200 Received: by calimero.vinschen.de (Postfix, from userid 500) id B3794A80704; Thu, 8 Aug 2019 10:57:34 +0200 (CEST) Date: Thu, 08 Aug 2019 08:57:00 -0000 From: Corinna Vinschen To: cygwin@cygwin.com Cc: Ken Brown , Michael Haubenwallner Subject: Re: Fork problem with hexchat if cygserver is running Message-ID: <20190808085734.GH11632@calimero.vinschen.de> Reply-To: cygwin@cygwin.com Mail-Followup-To: cygwin@cygwin.com, Ken Brown , Michael Haubenwallner References: <64c75d09-0771-901d-21bf-3ce10beecb38@ssi-schaefer.com> <20190808082440.GF11632@calimero.vinschen.de> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="jyWdsH1tvGESd50Z" Content-Disposition: inline In-Reply-To: <20190808082440.GF11632@calimero.vinschen.de> User-Agent: Mutt/1.11.3 (2019-02-01) X-SW-Source: 2019-08/txt/msg00121.txt.bz2 --jyWdsH1tvGESd50Z Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: quoted-printable Content-length: 2714 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 fail= ure: > > > [...] > > > 363 26064 [main] hexchat 12399 C:\cygwin64\bin\hexchat.exe: *** = fatal error=20 > > > in forked process - fixup_shms_after_fork: NtMapViewOfSection (0x7FF4= EE130000),=20 > > > status 0xC0000018. Terminating. > > >=20 > > > [status 0xC0000018 is STATUS_CONFLICTING_ADDRESSES.] > > >=20 > > > 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. > >=20 > > 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. >=20 > 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: >=20 > NtMapViewOfSection (0x7FF4EE130000) > ^^^^^^^^^^^^^^ >=20 > Note that this address is a 48 bit address, starting with 0x7f. >=20 > 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. >=20 > However, the above address is beyond even that, in the middle of the > address space utilized by Windows itself. Combine that with ASLR... >=20 > 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. >=20 > IMHO, the fix would be to make the mmap_alloc object global, so it > can be utilized by shmat() to create more sane addresses. >=20 > 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 --=20 Corinna Vinschen Cygwin Maintainer --jyWdsH1tvGESd50Z Content-Type: application/pgp-signature; name="signature.asc" Content-length: 833 -----BEGIN PGP SIGNATURE----- iQIzBAEBCAAdFiEEoVYPmneWZnwT6kwF9TYGna5ET6AFAl1L4/4ACgkQ9TYGna5E T6A+zw/9F/FNcngDgs9k+mv63y3aNYzYQm0ch4T4XTxStKrTNIXenrgf96PURSYg Gc8nHlR0dOrXCbHoBDbZzWXvwRKwxV1gW8JPW0r2jqIg7I6PIxZwMY50BGnPhn7M x26d+hS0mL7L/vQUDwNx59YowY9rnPjhljr7xP7lx80yn7siuCi+wiZz9U3hlV7Z ziTIq5H2dCmJEFzyyJ0MFdELdAY7L1RkuIffsUm4CDgdql8/DhdYNn5qY3V6zI/2 n4ghuEHJze8n2glqMgCtpQZGu7dPqrX+AFSMURJWQPg7DL5G8ET3BAv8zvqM+Fus MdQlUKEb5gsSLafYa1fWknij0HGyHJIxkVJIHE8Jlo1xhW8RAutoVCCo3AJgS/O0 vFmXVPd29G0Nr68G7P08ZOt9NB7ffRYz528AiMfRF+Np3Q0yrA+u1JjXGiDFistC 26s5huP6NB+mCNe2FAWxFzhICoP+FHyc9C/nLxRmUgocCMUF75xVFka6fBJ1lKPc Dq6QmKwgV7+Gw5xA8w5YwrJ730RvSOoDKKmGlAfE8rncxdl80wsLsvwu4O3kBWzA 5eu7jgPsnFtthvtRLpm44vpSYKWY3hTDmDgUAsOhJTPsA5uEVdcDACJDoiS+yaqu 1QBBF1Tmqb9+go2hdE6uj3KC8cYAXs2UDrta/N21uhEJ2RAdgjM= =G/sn -----END PGP SIGNATURE----- --jyWdsH1tvGESd50Z--