Osxfuse: Finder hangs while mounting using OS Fuse 3.6.3 on Mac OS 10.13

[lakshmi-subramanya]

Finder hangs resulting in system freeze at times while mounting Filr application on Mac 10.13 using OSX Fuse version 3.6.3.

This Finder hang is observed every time system is restarted.

The common sample of Filr and Finder hang is:

+                       2492 _DADispatchCallback  (in DiskArbitration) + 163  [0x7fff51eddc9e]
+                         2492 _VolumeObserverDiskAppearedCallback  (in CoreFoundation) + 334  [0x7fff5005eb6e]
+                           2492 CFURLCopyResourcePropertyForKey  (in CoreFoundation) + 283  [0x7fff4ffe20bb]
+                             2492 _FSURLCopyResourcePropertyForKeyInternal(__CFURL const*, __CFString const*, void*, void*, __CFError**, unsigned char)  (in CoreServicesInternal) + 214  [0x7fff63812bc7]
+                               2492 prepareValuesForBitmap(__CFURL const*, __FileCache*, _FilePropertyBitmap*, __CFError**)  (in CoreServicesInternal) + 312  [0x7fff638153ba]
+                                 2492 volumePropertyProviderPrepareValues(__CFURL const*, __FileCache*, __CFString const* const*, void const**, long, void const*, __CFError**)  (in CoreServicesInternal) + 400  [0x7fff6381af79]
+                                   2492 MountInfoPrepare(void***, unsigned int, int, void*, unsigned int const*, __CFURL const*, __CFError**)  (in CoreServicesInternal) + 43  [0x7fff63816c9d]
+                                     2492 FSMountPrepare  (in CarbonCore) + 69  [0x7fff51148f56]
+                                       2492 FSMount::FSMount(unsigned int, FSMountNumberType, int*, unsigned int const*)  (in CarbonCore) + 75  [0x7fff51148fdd]
+                                         2492 FileIDTreeGetAndLockVolumeEntryForDeviceID  (in CarbonCore) + 38  [0x7fff51149080]
+                                           2492 FSNodeStorageGetAndLockCurrentUniverse  (in CarbonCore) + 91  [0x7fff511491fe]
+                                             2492 _SCSessionUniverseByUIDAcquireAndLock  (in CarbonCore) + 346  [0x7fff51149746]
+                                               2492 _pthread_mutex_lock_slow  (in libsystem_pthread.dylib) + 253  [0x7fff77886551]
+                                                 2492 _pthread_mutex_lock_wait  (in libsystem_pthread.dylib) + 83  [0x7fff77888bfe]
+                                                   2492 __psynch_mutexwait  (in libsystem_kernel.dylib) + 10  [0x7fff7774deae]

---

Error message in console: (Not sure whether it is related message)

 Sep 28 16:28:36 devmac KernelEventAgent[99]: tid 54485244 received event(s) VQ_DEAD (32)

Sep 28 16:28:37 devmac kcm[2820]: DEPRECATED USE in libdispatch client: Setting timer interval to 0 requests a 1ns timer, did you mean FOREVER (a one-shot timer)?

We are using following options in our application: volicon, volname, daemon_timeout, local, allow_other.
Based on the issue 'https://github.com/osxfuse/osxfuse/issues/384', I removed local and/or allow_other. Still the hang is observed.

Is there any workaround or solution for this issue?
Note:

1. We are updating OSX Fuse framework from 3.5.0 to 3.6.3. Do we need to do some changes in our code to support 3.6.3 and resolve hang issue?
2. Issue is observed only on Mac OS 10.13 and not on Mac OS 10.12.x

Thanks.

[radj]

This also happens using osxfuse 3.7.1

[bfleischer]

Are you using the official FUSE 3.7.1 release or did you build FUSE yourself? Is Filr using libosxfuse or a different library, like bazil/fuse?

[lakshmi-subramanya]

We are using OSX Fuse officially released package, we install OSXFuse (silent installation) as part of Filr installation. We are using OSXFuse.framework and implementing those delegates using Objective C.

[lakshmi-subramanya]

Sample of FilrFS_FinderHang.txt
Sample of Finder.txt

Attached samples of both Filr Fuse component and Finder, when hang is observed for better understanding of the issue.

[radj]

@bfleischer The official one from releases page for my case.

Also we have the same stack with what was posted in OP. Starting from CFURLCopyResourcePropertyForKey and onwards. The difference is we were creating a CFURLRef to the mount point.

[radj]

Let me know if I should start a separate thread for this.

I was able to reproduce this on objective-C/LoopbackFS with a few minor changes (see patch in attached zip) to simulate what was happening in our code:

• Set deployment target to 10.10 to allow use of LSShared* APIs. This is deprecated (and probably makes this invalid) but doing this here to demonstrate the bug.
• When didMount: callback is invoked, attempt to create Finder sidebar item

Just run this and you should bump into the problem. Also in the zip is a sample of LoopbackFS when it is stuck.

Archive.zip

[lakshmi-subramanya]

Hi bfleischer,

Is there any updates on this issue? This is blocking our release that supports Mac OS 10.13.

We are facing the hang whenever our code access file system to access any files or while copying files from bundle to app support location.
Once we unmount our Filr, the Finder hang is not observed, system is back to normal.

Hoping for the speedy response on this issue.

[bfleischer]

@radj Thanks for the patch.

Calling back into the file system in the didMount: handler is a bad idea and will in most cases lead to a file system deadlock. This is not a bug in FUSE. Please keep in mind that at the point of your [self createSidebarItem:mountPath] call the volume has already been mounted but file system requests are not served until after didMount: returns.

So, if you (or a function you call) synchronously accesses the file system in didMount: you end up with a deadlock. This has always been the case. As far as I know Apple made some changes to the way CFURL and NSURL fetch (and cache) volume attributes in High Sierra. This might be the reason your code works on Sierra but doesn't on High Sierra.

As a workaround you could dispatch the [self createSidebarItem:mountPath] asynchronously:

dispatch_async(dispatch_get_main_queue(), ^{
    [self createSidebarItem:mountPath];
});

[bfleischer]

@lakshmi-subramanya Judging from the FilrFS sample you are calling LSSharedFileListInsertItemURL() in your didMount: handler. This will lead to a deadlock on High Sierra. For details see my previous response to @radj. Adding the sidebar item asynchronously should work.

Hoping for the speedy response on this issue.

I would like to comment on this. As you know FUSE for macOS is open source and can be freely used by anyone. But the fact that a software is available for free, does in no way imply that maintaining and supporting it do not cost a lot of time and money.

Let's be clear here, Micro Focus is bundling FUSE for macOS with Filr and sells it to other companies. Despite the fact the FUSE is a key component for Filr, Micro Focus does not support the continued development of FUSE for macOS. And here you are are asking for a speedy response. Does this sound fair to you?

If you come to the same conclusion as me, you can find my email address on my GitHub profile.

[radj]

@bfleischer Makes a lot of sense! Thanks for pointing that out. Our work around for this was to delay the sidebar item creation via delayed dispatch but we will change to do the dispatch to main queue instead.