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:subject:message-id:reply-to
	:references:mime-version:content-type:in-reply-to; q=dns; s=
	default; b=aJgSKhRJl6yIOyQHJSb5RAR8mSZxz6iaZjr+b1N+zu2siFFms0ieY
	OdnKXvej7GPWtG8dfLpvDpAB5X9gknnfAVRzWLfl5oCQJ1NI2/jT5KqlwJEAEkB6
	8WYxh9UyJRgB62xseLfVUVvw/VPN5eN3qBKQu9wSI23h94q/j2tbus=
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:subject:message-id:reply-to
	:references:mime-version:content-type:in-reply-to; s=default;
	bh=rhfC9Kteb34p2uRbJzu5Shen4HE=; b=YRyTQwGa8PYmNiXNRbb3AGyA0eJU
	lgt9qMkkDY595McI1HQ8J/tWl2YcH7eTPFn2PMBBDBw/JITb1czPeKyJXrDa7f7Q
	Kkm92xaoB54NOGqliYfKx0tX5mcMYvriOAQNGMSQHoYOUv2zfMSxgiZD0ZwKLbLK
	8X5yKi6YQ+SiiFw=
Mailing-List:	contact cygwin-help AT cygwin DOT com; run by ezmlm
List-Id:	<cygwin.cygwin.com>
List-Subscribe:	<mailto:cygwin-subscribe AT cygwin DOT com>
List-Archive:	<http://sourceware.org/ml/cygwin/>
List-Post:	<mailto:cygwin AT cygwin DOT com>
List-Help:	<mailto:cygwin-help AT cygwin DOT com>, <http://sourceware.org/ml/#faqs>
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-Virus-Found:	No
X-Spam-SWARE-Status:	No, score=-96.3 required=5.0 tests=AWL,BAYES_00,GOOD_FROM_CORINNA_CYGWIN,KAM_LAZY_DOMAIN_SECURITY,RCVD_IN_PBL,RCVD_IN_SORBS_DUL,RDNS_DYNAMIC autolearn=ham version=3.3.2 spammy=H*MI:sk:billzis, H*f:sk:billzis, H*MI:D38743FD.926E, Hx-languages-length:2562
X-HELO:	calimero.vinschen.de
Date:	Thu, 16 Jun 2016 11:05:33 +0200
From:	Corinna Vinschen <corinna-cygwin AT cygwin DOT com>
To:	cygwin AT cygwin DOT com
Subject:	Re: Fork and Windows Heap
Message-ID:	<20160616090533.GG27295@calimero.vinschen.de>
Reply-To:	cygwin AT cygwin DOT com
Mail-Followup-To:	cygwin AT cygwin DOT com
References:	<D38743FD.926E%billziss AT navimatics DOT com>
MIME-Version:	1.0
In-Reply-To:	<D38743FD.926E%billziss@navimatics.com>
User-Agent:	Mutt/1.6.1 (2016-04-27)

--O3RTKUHj+75w1tg5
Content-Type: text/plain; charset=utf-8
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable

Hi Bill,

On Jun 16 00:42, Bill Zissimopoulos wrote:
> I am the creator of WinFsp [1], a user mode file system solution for
> Windows (i.e. FUSE for Windows). WinFsp has its own API, but I have been
> working on adding a FUSE (high-level) API using SSHFS as my primary test
> case. This has proven to work very well, except for one important problem
> which is the subject of my post.
>=20
> FUSE provides an API fuse_daemonize() that allows a FUSE file system to
> become a daemon, which SSHFS uses. I have provided a simple implementation
> using daemon(3), which of course uses fork. Unfortunately SSHFS crashes
> whenever it is daemonized and I have traced the failure to an invalid
> Windows heap pointer.
>=20
> WinFsp consists of an FSD (file system driver) and a DLL component. The
> WinFsp DLL uses the Windows heap functions to manage memory
> (HeapAlloc/HeapFree). It seems that the Windows heap is not properly
> cloned after a fork, which leads to the crash I am experiencing. I have
> the following questions:
>=20
> (1) Is my assumption that Windows heaps are not properly cloned after a
> fork correct? A 2011 post [2] seems to suggest so.

You are correct.  Cygwin fork only clones the datastructures explicitely
set up by Cygwin and stuff allocated using Cygwin's POSIX API.

You can't simply clone a Windows heap for various reasons:

- There's no information given how Windows keeps track over its heaps
  so we don't know how to clone this information.

- A child process will get its own default heap at startup, in another
  memory location than its parent (ASLR).

- Data from non-Cygwin DLLs is inherently not fork-safe.  Especially
  data from DLLs like user32.dll is not simply clonable.  Given that
  cloning is unprovided for, may Windows DLLs will run their own
  initilization code at DLL starttime and creat their completely
  disjunct set of data.  Stuff like connecting to the current
  Windows console fails, etc.

> (2) Is there any workaround that the WinFsp DLL can use to get around this
> limitation and work properly after a fork? The obvious answer would be to
> have the DLL use Cygwin's malloc/free and this is indeed possible within
> the DLL's FUSE layer, but not workable elsewhere.

Exactly.  Ideally, you would provide two DLLs, one for native Windows
using Windows functions, the other for Cygwin, linked against Cygwin and
using POSIX functions only.

Granted, that's a bit more work :}


HTH,
Corinna

--=20
Corinna Vinschen                  Please, send mails regarding Cygwin to
Cygwin Maintainer                 cygwin AT cygwin DOT com
Red Hat

--O3RTKUHj+75w1tg5
Content-Type: application/pgp-signature; name="signature.asc"

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2

iQIcBAEBCAAGBQJXYmvdAAoJEPU2Bp2uRE+gDFoQAJcNB7dckjMkPznUhgdzoRlm
ScGz+ui+1WFDSWr0KZefopQWuc3zw7/5bEIZYsHQCugBpSjni0L/KYz66aBSONhe
v+5QwSQYRAtlMPuLDzxmHEgISzHEGv9UeRmi07OkHnUWkafu3rYWglJSasxAYqDP
6KzSKPIDiR2iVXU7fGVXIzg3/yVm2hlirHMDP91z1N0aU88brfx9N2zNOgjoOGdI
UqV/aYjxSNJ60SsORslAIM5dZNZQCBocYmBgVAp8XMSy+keBud3MA66a3C54yu3b
OBy530KW5xtLHQhcSIEN4c1oTnwEeFmiMc1FufYq3UdXOhhAlwZzUNsjsM0o8QcX
Jxfj+BLobCskHTVQgyaRP4I7cPd4tmORoH/S2U4V7LUfeR4unPOJd+Hh6tW8nWJE
+FaGRXM1XVUtC2vqI8WUsHTDo3e08GQJ6KCOU64ecYLKGplCK2Y/hpvT8R/ErRu0
F8W5xmwmRn61oqpMDy132LRM4B19asdAt+ljeXIT/sJa3mdKDNI1lxzKgCfL5a9I
Xuaxnil7RuicXY43W9ExsbaGBoKoQHwKaeKd30M+0UlgwjoAr0i/co+VmwiTHp6q
Tx0fD+YB7eTNRQdxiPgipJzTZrdc7ay+5PF4DBmfmK3Ng2n2FdK3TgJe2btZ3O5q
uu/ejRJddJwCEurmqYXY
=eHAS
-----END PGP SIGNATURE-----

--O3RTKUHj+75w1tg5--

- Raw text -