From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 124050 invoked by alias); 24 Feb 2019 19:09:18 -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 124017 invoked by uid 89); 24 Feb 2019 19:09:18 -0000 Authentication-Results: sourceware.org; auth=none X-Spam-SWARE-Status: No, score=-125.9 required=5.0 tests=BAYES_00,GIT_PATCH_0,GIT_PATCH_1,GIT_PATCH_2,GIT_PATCH_3,GOOD_FROM_CORINNA_CYGWIN,KAM_LAZY_DOMAIN_SECURITY,RCVD_IN_DNSWL_NONE autolearn=ham version=3.3.2 spammy=Hx-languages-length:2689, explain X-HELO: mout.kundenserver.de Received: from mout.kundenserver.de (HELO mout.kundenserver.de) (217.72.192.75) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Sun, 24 Feb 2019 19:09:16 +0000 Received: from calimero.vinschen.de ([24.134.7.25]) by mrelayeu.kundenserver.de (mreue108 [212.227.15.183]) with ESMTPSA (Nemesis) id 1MFba4-1gnVpT2uUg-00H64z; Sun, 24 Feb 2019 20:09:09 +0100 Received: by calimero.vinschen.de (Postfix, from userid 500) id 5B578A8092D; Sun, 24 Feb 2019 20:09:08 +0100 (CET) Date: Sun, 24 Feb 2019 19:53:00 -0000 From: Corinna Vinschen To: Ken Brown Cc: cygwin Subject: Re: Fork issue with timerfd Message-ID: <20190224190908.GB10574@calimero.vinschen.de> Reply-To: cygwin@cygwin.com Mail-Followup-To: Ken Brown , cygwin References: <20190224185524.GE4133@calimero.vinschen.de> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="24zk1gE8NUlDmwG9" Content-Disposition: inline In-Reply-To: <20190224185524.GE4133@calimero.vinschen.de> User-Agent: Mutt/1.11.3 (2019-02-01) X-SW-Source: 2019-02/txt/msg00404.txt.bz2 --24zk1gE8NUlDmwG9 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: quoted-printable Content-length: 2809 On Feb 24 19:55, Corinna Vinschen wrote: > On Feb 24 17:27, Ken Brown wrote: > > I'm seeing sporadic errors like this on 64-bit Cygwin when I first star= t emacs: > >=20 > > 0 [main] emacs-X11 864 C:\cygwin64\bin\emacs-X11.exe: *** fatal = error in=20 > > forked process - Can't recreate shared timerfd section during fork! > > 0 [main] emacs 860 dofork: child 864 - died waiting for dll load= ing, errno 11 > >=20 > > If I exit and restart, everything will be fine almost every time. >=20 > I think I see where the thinko was here. Can you try this? No, better try this: diff --git a/winsup/cygwin/timerfd.cc b/winsup/cygwin/timerfd.cc index 7e6be72b225a..a587926eed28 100644 --- a/winsup/cygwin/timerfd.cc +++ b/winsup/cygwin/timerfd.cc @@ -408,6 +408,7 @@ void timerfd_tracker::fixup_after_fork_exec (bool execing) { NTSTATUS status; + PVOID base_address =3D NULL; OBJECT_ATTRIBUTES attr; SIZE_T vsize =3D PAGE_SIZE; =20 @@ -416,11 +417,12 @@ timerfd_tracker::fixup_after_fork_exec (bool execing) return; /* Recreate shared section mapping */ status =3D NtMapViewOfSection (tfd_shared_hdl, NtCurrentProcess (), - (void **) &tfd_shared, 0, PAGE_SIZE, NULL, - &vsize, ViewShare, MEM_TOP_DOWN, PAGE_READWRITE); + &base_address, 0, PAGE_SIZE, NULL, + &vsize, ViewShare, 0, PAGE_READWRITE); if (!NT_SUCCESS (status)) - api_fatal ("Can't recreate shared timerfd section during %s!", - execing ? "execve" : "fork"); + api_fatal ("Can't recreate shared timerfd section during %s, status %y= !", + execing ? "execve" : "fork", status); + tfd_shared =3D (timerfd_shared *) base_address; /* Increment global instance count by the number of instances in this process */ InterlockedAdd (&tfd_shared->instance_count, local_instance_count); To explain: The memory address of the shared region doesn't matter at all, so fixup_after_fork_exec just has to re-open the shared timerfd region anywhere. But here's the deal per MSDN: "If the value of [BaseAddress] is not NULL, the view is allocated starting at the specified virtual address [...]" But I made a mistake: I gave the pointer to &tfd_shared to NtMapViewOfSection, which is only NULL in the parent, while it has the parent's value in the child process. Combined with the MEM_TOP_DOWN allocation, this may collide with mmapped regions from the parent. So the above code now always sets BaseAddress to NULL in the call to NtMapViewOfSection and only copies over the address of the mapping to the tfd_shared pointer afterwards. It also drops the MEM_TOP_DOWN allocation which doesn't make any sense here. And last but not least, it prints the status code on failure for future debugging. Thanks, Corinna --=20 Corinna Vinschen Cygwin Maintainer --24zk1gE8NUlDmwG9 Content-Type: application/pgp-signature; name="signature.asc" Content-length: 833 -----BEGIN PGP SIGNATURE----- iQIzBAEBCAAdFiEEoVYPmneWZnwT6kwF9TYGna5ET6AFAlxy69QACgkQ9TYGna5E T6BIVw/+LWkz052Ur7QbDnemvWeazX9nlZaavyBlz4HLA+nU4lhokNgj/Co3RfLx DSkIZLQfMChGo5ul5ZFFQ4OVIjdt72TuaWL+1ECGSEfIk0hLdJEp1yVOBD5NcoWS wGUjggUsnjagFwS0lS/0p/lBBd5mRIZmH5FzTomtpnQWkN1bB6KVw0b2A3/7MgA3 NC2Z4usEWNSyOeTcLlcApyIUyr5PLFLi9YFeoPcjSgeNthkBV/eKQMdATvH5i5GV 7/oYQDnY6YoSvv+GqV9XmhDiXYxPKm6q8EBVlQuyW+nwyZPei2jPLRbe6//A9JmV c9m28pgm8K6nk7v3Y1lcNWf22ujHxUWt3x7vIqQTUh/4RW8akeMnaAn5Rhn/vHkE 4TTx2rR/SBKGgeWABwUcrmOqAPolq4LxbPPK7QEQlwSD/5RI54V4637Z6bSraGt0 g5uU0cDQ5247TdeilPLVqJWsNMaegBLgSapWG6fj0qztt21lgNQtBPo6Ckj+jafU 5/xNqcO2yw9IxTXm4FUlt/JckzP2NNMa5ZUvvrwjWE3/wjv5YEddh7mCI9oztIjg ID1I1nWut2Q8ZV5SsjzudJB0eKAgCa5Bi5wbyDVxex+XYpY5/KCGIIpmqqbwNlDb z4U2j/wd/UPB7PY9eDXfiSCHgTc9ydK4MfJpNJC7fHxnNFkayGg= =JXhK -----END PGP SIGNATURE----- --24zk1gE8NUlDmwG9--