X-Recipient: archive-cygwin AT delorie DOT com DomainKey-Signature: a=rsa-sha1; c=nofws; d=sourceware.org; h=list-id :list-unsubscribe:list-subscribe:list-archive:list-post :list-help:sender:date:from:to:cc:subject:message-id:reply-to :references:mime-version:content-type:in-reply-to; q=dns; s= default; b=a2y7IdEdVJnUcB+qyRDuNMdIV41yoz0mlkHLmxQvrpeeFHN5rWMZA RNvEwRGuDUBq51qlMf9LNPPETBqpT6hbVBDvaAi48nNwjVYRbc1Vn0Q0zmpkz1zP zOES9diXyvtRQlGiHjj1aCVCpFyPNoeRDeP85seNgBk8n9bN0uczbk= DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=sourceware.org; h=list-id :list-unsubscribe:list-subscribe:list-archive:list-post :list-help:sender:date:from:to:cc:subject:message-id:reply-to :references:mime-version:content-type:in-reply-to; s=default; bh=BQK1g0mh2bBfAfeYqX/B2uJt8j4=; b=KthavSt9W/x66UEjV8/ySy+55D2v hU+5PAVw9L8bJzLeOpktcGxIpsODFHm1FY9OwHG7f0g9cFWcykkXiozbyJYbEqZY TVRMZZ+hjXuLU1PcDqgOKGyZI/rSlYRoAmwiBv57XM83CGf0VRXoOskcYPTlBmTT uagH4MIY2/ESMek= Mailing-List: contact cygwin-help AT cygwin DOT com; run by ezmlm List-Id: List-Subscribe: List-Archive: List-Post: List-Help: , Sender: cygwin-owner AT cygwin DOT com Mail-Followup-To: cygwin AT cygwin DOT com Delivered-To: mailing list cygwin AT cygwin DOT com Authentication-Results: sourceware.org; auth=none X-Spam-SWARE-Status: No, score=-104.3 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 Date: Thu, 8 Aug 2019 10:24:40 +0200 From: Corinna Vinschen To: Michael Haubenwallner Cc: cygwin AT cygwin DOT com, Ken Brown Subject: Re: Fork problem with hexchat if cygserver is running Message-ID: <20190808082440.GF11632@calimero.vinschen.de> Reply-To: cygwin AT cygwin DOT com Mail-Followup-To: Michael Haubenwallner , cygwin AT cygwin DOT com, Ken Brown References: <64c75d09-0771-901d-21bf-3ce10beecb38 AT ssi-schaefer DOT com> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="KS5V1uDxmEcBh2BA" Content-Disposition: inline In-Reply-To: <64c75d09-0771-901d-21bf-3ce10beecb38@ssi-schaefer.com> User-Agent: Mutt/1.11.3 (2019-02-01) --KS5V1uDxmEcBh2BA Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: quoted-printable 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 failur= e: > > [...] > > 363 26064 [main] hexchat 12399 C:\cygwin64\bin\hexchat.exe: *** fa= tal error=20 > > in forked process - fixup_shms_after_fork: NtMapViewOfSection (0x7FF4EE= 130000),=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 fe= els > like an address conflict with some (internal) memory allocated for some W= indows > (or even Cygwin) object. > So I'd wonder if early memory reservation like is done for dynamically lo= aded > 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 --=20 Corinna Vinschen Cygwin Maintainer --KS5V1uDxmEcBh2BA Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQIzBAEBCAAdFiEEoVYPmneWZnwT6kwF9TYGna5ET6AFAl1L3EcACgkQ9TYGna5E T6BxfA//Vp1L0vgY+VNu6AjdufV/JrE5wV0SatD1LyiqS9vxcRFCGb3vJwi+yEsD WsnMqB/o2Ag7jyTD7A6ZGoe2KHPFkgO1u+OhpzHf1D8r5yuD9Ghbv/CGMQ6D7qTf Fl/wExfUpAIxccUf33uUkco+tF6kFCRsPWKSGN7/KLKuueJoyQt98Obrv4Ma1wix UOMqULYIwQSj04pVuKJZnvR2RA4TKb05kXgHMxCcHRs1OhrdyoFKIvli0IT5CpZn qACFp5C6xjaE0ic4z6lFesGmqJeINNwlQyyElyMxU6uyWSAAG0xuWXKB7uchacvP Cfa4TYX4VGKDJnk3vKIRRhiLewbTpA/+KISVUINSMNega6bX8TzgT4uyTBTLIUU8 VEG3/mDTZGU6Qxb2h9ppc+G5k8bPwuSkJwhoFvxoYGfWMCecHmbcKvbD0ehAhkgL 2weby1UuxmaVo2nkBcGqu7a8wwxCJJxKVU2zkhUiO1AQ8pmVOoJvFg8vO7vxqRWk p8pLH+Kzq+pgXD7I2m468wYvBVTc18r7HYAcFmpHcZiRgWZ9V6sllK0eWj+UHe0P 9Pss/C7wmh13rFJRUCSp80YQD9t/jZH2Fpe78jp5SGKfU9fSz+zriYPykXpi6Si5 M5JpMQ0zja3N6FX69gXBwLZqwiQpsqVhVhTj8J8m7ocqO+50GNA= =BCB7 -----END PGP SIGNATURE----- --KS5V1uDxmEcBh2BA--