public inbox for cygwin@cygwin.com
 help / color / mirror / Atom feed
From: Bill Zissimopoulos <billziss@navimatics.com>
To: "cygwin@cygwin.com" <cygwin@cygwin.com>
Subject: Fork and Windows Heap
Date: Thu, 16 Jun 2016 06:37:00 -0000	[thread overview]
Message-ID: <D38743FD.926E%billziss@navimatics.com> (raw)

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


             reply	other threads:[~2016-06-16  0:42 UTC|newest]

Thread overview: 5+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2016-06-16  6:37 Bill Zissimopoulos [this message]
2016-06-16  9:05 ` René Berber
2016-06-16 12:49 ` Corinna Vinschen
2016-06-16 12:44 Bill Zissimopoulos
2016-06-17  7:25 Bill Zissimopoulos

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=D38743FD.926E%billziss@navimatics.com \
    --to=billziss@navimatics.com \
    --cc=cygwin@cygwin.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).