DomainKey-Signature: a=rsa-sha1; c=nofws; d=sourceware.org; h=list-id
	:list-unsubscribe:list-subscribe:list-archive:list-post
	:list-help:sender:from:to:subject:date:message-id:content-type
	:content-id:content-transfer-encoding:mime-version; q=dns; s=
	default; b=GBkU4EYLZg44ykFqg/RoFkg9CoRSqKqPjUkKNnNWN5qVYlTFeCAjG
	ABEMgLK/+Vw5veEtrzFIrRC5ZyLrUuXevya3w2JZBhgX+6Eqzc9kQaFWFwD0XApQ
	c09Om0Pmlv9eRyoPQtS0xbS455PGFxZX/WuF0WjxiCVisrp2TpkoR0=
Mailing-List: contact cygwin-help AT cygwin DOT com; run by ezmlm
Sender: cygwin-owner AT cygwin DOT com
Mail-Followup-To: cygwin AT cygwin DOT com
From: Bill Zissimopoulos <billziss AT navimatics DOT com>
To: "cygwin AT cygwin DOT com" <cygwin AT cygwin DOT com>
Subject: Fork and Windows Heap
Date: Thu, 16 Jun 2016 00:42:24 +0000
Message-ID: <D38743FD.926E%billziss@navimatics.com>
x-ms-exchange-messagesentrepresentingtype: 1
x-ms-office365-filtering-correlation-id: 45105b41-0175-448a-f64b-08d3957f1627
x-microsoft-exchange-diagnostics: 1;CY1PR07MB2199;5:E7UfwFeKpZ2qeSNuFaSc4mUHLIjhJ9lTdn8ibURB3Sc/sGGco1RdsmhFlH8iDAV6h21B7BO5q6bFNPRBRrvnK610c0BlKOZBCwmjuNggUanUqWfjKBdO7Yl/odmGVrFd9r9O+WkV0NYsJIjVlydJ5Q==;24:Og54R0Ei+gJUuaMSU3H0aeQQ/dtYkhuBlx8RuXxkYlf+dhAobAaK2/x2Q9uRkxa5hakp3uViAUjBgHK7qRGP9PbC7MN1aJyx0xekFuHaYsM=;7:iPPUhjXXI8aDhM3h2rOz4ZogRH2X6IbO8EGt0q4rhFwXrHWCw98qct/zsdofJ1gM0ujVesnmQdJTgA5N0zdj9G9VXC7QjObT1gCJK7v/d6XCTJzOT0JapdGKUAYj4ijF59VzCQNd+o8NBg/nTDfE+RebFdcjrJ0Io8p6ybfmK7Xi5oPNbaZ/tsg0vi5X6XjANCAKI9iKlmbL+8GCC/wnOA==
x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:CY1PR07MB2199;
x-microsoft-antispam-prvs: <CY1PR07MB2199CFA12F4CD3EF023467F3BC560 AT CY1PR07MB2199 DOT namprd07 DOT prod DOT outlook DOT com>
x-exchange-antispam-report-test: UriScan:(148717330147763);
x-exchange-antispam-report-cfa-test: BCL:0;PCL:0;RULEID:(6040130)(601004)(2401047)(5005006)(8121501046)(10201501046)(3002001)(6041072)(6043046);SRVR:CY1PR07MB2199;BCL:0;PCL:0;RULEID:;SRVR:CY1PR07MB2199;
x-forefront-prvs: 09752BC779
x-forefront-antispam-report: SFV:NSPM;SFS:(10019020)(6009001)(7916002)(189002)(199003)(105586002)(106116001)(10400500002)(122556002)(450100001)(106356001)(5002640100001)(86362001)(87936001)(2351001)(19580395003)(92566002)(99286002)(66066001)(229853001)(36756003)(586003)(5004730100002)(54356999)(11100500001)(2900100001)(8936002)(189998001)(50986999)(8676002)(1730700003)(81166006)(81156014)(2906002)(68736007)(5640700001)(97736004)(110136002)(77096005)(102836003)(3480700004)(15975445007)(3660700001)(6116002)(3846002)(2501003)(5008740100001)(3280700002)(101416001)(107886002)(94096001)(69594002);DIR:OUT;SFP:1102;SCL:1;SRVR:CY1PR07MB2199;H:CY1PR07MB2199.namprd07.prod.outlook.com;FPR:;SPF:None;PTR:InfoNoRecords;MX:1;A:1;LANG:en;
received-spf: None (protection.outlook.com: navimatics.com does not designate permitted sender hosts)
spamdiagnosticoutput: 1:99
spamdiagnosticmetadata: NSPM
Content-Type: text/plain; charset="utf-8"
Content-ID: <8C14CC707A3BCC42AFD2DFE407F47468 AT namprd07 DOT prod DOT outlook DOT com>
MIME-Version: 1.0
X-OriginatorOrg: navimatics.com
X-MS-Exchange-CrossTenant-originalarrivaltime: 16 Jun 2016 00:42:24.6037 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: 21071be9-4f9a-413b-89ac-8353a5d2410a
X-MS-Exchange-Transport-CrossTenantHeadersStamped: CY1PR07MB2199
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from base64 to 8bit by delorie.com id u5G0goAM028973

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.

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.

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:

(1) Is my assumption that Windows heaps are not properly cloned after a
fork correct? A 2011 post [2] seems to suggest so.
(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.

Any insights welcome.

Bill Zissimopoulos

[1] http://www.secfs.net/winfsp/
[2] https://www.cygwin.com/ml/cygwin-developers/2011-04/msg00035.html