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=CNXQbKRzkxY3yH1aqdC5xU3cUW2NRuPd9QufjyJHWYV2E0PgZZ/Rq
	RLRbpRsg2/Q9Wz+OVEzNtGHLMuYYaPwqZnTTALiqD5KtYheQ2X6Gly7CYfEPSgcf
	i+CwLJPLTTJEnnlxki3cD5+RGJFQkRMqqM5kLnJ+eGrh/UgFKwMIjI=
Mailing-List: contact cygwin-help@cygwin.com; run by ezmlm
Sender: cygwin-owner@cygwin.com
Mail-Followup-To: cygwin@cygwin.com
Date: Sun, 24 Feb 2019 20:09:08 +0100
From: Corinna Vinschen <corinna-cygwin@cygwin.com>
To: Ken Brown <kbrown@cornell.edu>
Cc: cygwin <cygwin@cygwin.com>
Subject: Re: Fork issue with timerfd
Message-ID: <20190224190908.GB10574@calimero.vinschen.de>
Reply-To: cygwin@cygwin.com
Mail-Followup-To: Ken Brown <kbrown@cornell.edu>,	cygwin <cygwin@cygwin.com>
References: <ca9a38b7-c147-78a3-0660-70aa65b41eb3@cornell.edu> <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)

--24zk1gE8NUlDmwG9
Content-Type: text/plain; charset=utf-8
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable

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"

-----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--