Bug 58367 - Xamarin.Mac crash when returning to native code of a binding library
Summary: Xamarin.Mac crash when returning to native code of a binding library
Alias: None
Product: Xamarin.Mac
Classification: Desktop
Component: Runtime ()
Version: unspecified
Hardware: Macintosh Mac OS
: --- normal
Target Milestone: 15.4
Assignee: Rolf Bjarne Kvinge [MSFT]
Depends on:
Reported: 2017-07-25 14:35 UTC by brad.medinger
Modified: 2017-08-02 12:04 UTC (History)
3 users (show)

Is this bug a regression?: No
Last known good build:

crash log (13.58 KB, text/rtf)
2017-07-25 14:36 UTC, brad.medinger
OSXFUSE Loopback sample (186.53 KB, application/zip)
2017-07-25 14:37 UTC, brad.medinger
OSXFUSE Binding Library Project (944.75 KB, application/zip)
2017-07-25 14:38 UTC, brad.medinger
Xamarin.Mac Loopback Sample (504.05 KB, application/zip)
2017-07-25 14:41 UTC, brad.medinger

Notice (2018-05-24): bugzilla.xamarin.com is now in read-only mode.

Please join us on Visual Studio Developer Community and in the Xamarin and Mono organizations on GitHub to continue tracking issues. Bugzilla will remain available for reference in read-only mode. We will continue to work on open Bugzilla bugs, copy them to the new locations as needed for follow-up, and add the new items under Related Links.

Our sincere thanks to everyone who has contributed on this bug tracker over the years. Thanks also for your understanding as we make these adjustments and improvements for the future.

Please create a new report on Developer Community or GitHub with your current version information, steps to reproduce, and relevant error messages or log files if you are hitting an issue that looks similar to this resolved bug and you do not yet see a matching new report.

Related Links:

Description brad.medinger 2017-07-25 14:35:45 UTC
I’m using OSXFUSE (https://osxfuse.github.io) in a Xamarin.Mac project to mount a volume that is backed by a remote file system.  The issue I’m running into with this is that every time an extended attribute is set on a file, the entire application crashes.  I can consistently recreate this in our application.

OSXFUSE has a sample loopback application to mount a volume thats backed by some other local folder, and I’ve verified that setting extended attributes works fine from their Objective-C sample.  I’ve converted their Objective-C sample to a Xamarin.Mac project, as best as I could, and now I’m getting the same crash when setting extended attributes.

The sample Xamarin.Mac project mounts the user's home directory as a volume named 'xamLoopback'.  This issue can easily be recreated by using the Finder to set a tag on a file in that mounted volume.  When I do that and debug the SetExtendedAttribute method of my FileSystemDelegate, I can see that my code is being called from OSXFUSE.  As soon as I return from this method is when the crash occurs.  I’m even able to set the extended attribute on the file and can verify with Finder that the tag is set on the backing file in the user's home directory.

I believe this is a bug in Xamarin because the Objective-C sample works fine, but my Xamarin.Mac sample fails when it seems like its doing the same thing.  I’ve been over my binding library project and don’t see anything wrong with the SetExtendedAttribute method, but maybe I’m still missing something. 

From the crash log, it looks like something is blowing up when returning back to the native code.  This is the thread that I believe is causing the issue from the crash log of my Xamarin.Mac loopback sample application:

thread #8, name = 'tid_c003'
    frame #0: 0x00007fff8e9773ee libsystem_kernel.dylib`__wait4 + 10
    frame #1: 0x0000000104774c4e XamLoopback`mono_handle_native_crash(signal=<unavailable>, ctx=<unavailable>, info=<unavailable>) at mini-exceptions.c:2567 [opt]
    frame #2: 0x00000001046f3516 XamLoopback`altstack_handle_and_restore(ctx=0x000070000de403b0, obj=0x0000000000000000, stack_ovf=0) at exceptions-amd64.c:780 [opt]
    frame #3: 0x000000010468e20a XamLoopback`::xamarin_invoke_trampoline(type=Tramp_Default, self=0x00006080000110d0, sel="setExtendedAttribute:ofItemAtPath:value:position:options:error:", iterator=(XamLoopback`param_iter_next(IteratorAction, void*, char const*, unsigned long, void*, unsigned int*) at trampolines-x86_64.m:236), marshal_return_value=(XamLoopback`marshal_return_value(void*, char const*, unsigned long, void*, _MonoType*, bool, _MonoMethod*, unsigned int*) at trampolines-x86_64.m:302), context=0x000070000de40af8) at trampolines-invoke.m:496
    frame #4: 0x000000010468f05d XamLoopback`::xamarin_arch_trampoline(state=0x000070000de40b40) at trampolines-x86_64.m:540
    frame #5: 0x0000000104690421 XamLoopback`xamarin_x86_64_common_trampoline + 110
    frame #6: 0x0000000104ce8e11 OSXFUSE`___lldb_unnamed_symbol109$$OSXFUSE + 253
    frame #7: 0x0000000104de0888 libosxfuse.2.dylib`fuse_fs_setxattr + 160
    frame #8: 0x0000000104df54e0 libosxfuse.2.dylib`___lldb_unnamed_symbol376$$libosxfuse.2.dylib + 243
    frame #9: 0x0000000104de0888 libosxfuse.2.dylib`fuse_fs_setxattr + 160
    frame #10: 0x0000000104de7a44 libosxfuse.2.dylib`___lldb_unnamed_symbol101$$libosxfuse.2.dylib + 182
    frame #11: 0x0000000104deb641 libosxfuse.2.dylib`___lldb_unnamed_symbol162$$libosxfuse.2.dylib + 81
    frame #12: 0x0000000104ded788 libosxfuse.2.dylib`___lldb_unnamed_symbol199$$libosxfuse.2.dylib + 1754
    frame #13: 0x0000000104def007 libosxfuse.2.dylib`fuse_session_process_buf + 22
    frame #14: 0x0000000104de9dbc libosxfuse.2.dylib`fuse_session_loop + 202
    frame #15: 0x0000000104de5aa0 libosxfuse.2.dylib`fuse_loop + 523
    frame #16: 0x0000000104df0948 libosxfuse.2.dylib`___lldb_unnamed_symbol240$$libosxfuse.2.dylib + 82
    frame #17: 0x0000000104df0990 libosxfuse.2.dylib`fuse_main_real + 15
    frame #18: 0x0000000104ce8a46 OSXFUSE`___lldb_unnamed_symbol107$$OSXFUSE + 1732
    frame #19: 0x00007fff7aaf1b3d Foundation`__NSThread__start__ + 1243
    frame #20: 0x00007fff8ea6193b libsystem_pthread.dylib`_pthread_body + 180
    frame #21: 0x00007fff8ea61887 libsystem_pthread.dylib`_pthread_start + 286
    frame #22: 0x00007fff8ea6108d libsystem_pthread.dylib`thread_start + 13

I’ll attached the full crash log, Xamarin.Mac sample loopback project, OSXFUSE binding library project, and the OSXFUSE Objective-C sample loopback project.  You'll need to install the OSXFUSE framework to be able to run either sample application.

OSXFUSE: 3.6.3
Xamarin Studio: 6.2 (build 1821)
Mono: 4.8.0
Xcode: 8.3.3
MacOS: 10.12.5
Comment 1 brad.medinger 2017-07-25 14:36:40 UTC
Created attachment 23789 [details]
crash log
Comment 2 brad.medinger 2017-07-25 14:37:39 UTC
Created attachment 23790 [details]
OSXFUSE Loopback sample

LoopbackFS.zip is the Objective-C loopback sample provided by OSXFUSE.
Comment 3 brad.medinger 2017-07-25 14:38:52 UTC
Created attachment 23791 [details]
OSXFUSE Binding Library Project
Comment 4 brad.medinger 2017-07-25 14:41:41 UTC
Created attachment 23792 [details]
Xamarin.Mac Loopback Sample

XamLoopback.zip is the Xamarin.Mac project I created to mimic the Objective-C loopback sample project.  This is the project that recreates the issue.
Comment 5 Rolf Bjarne Kvinge [MSFT] 2017-08-01 11:58:27 UTC
This seems to be a problem with the dynamic registrar. If I select the static registrar (pass --registrar:static as an additional mmp argument in the project's Mac Build options), the crash goes away.

This should be a viable workaround (the build will take a little longer, but otherwise everything should work fine - also note that release builds use the static registrar by default).
Comment 6 Rolf Bjarne Kvinge [MSFT] 2017-08-01 13:54:55 UTC
Comment 7 Rolf Bjarne Kvinge [MSFT] 2017-08-02 07:00:06 UTC
d15-4: https://github.com/xamarin/xamarin-macios/pull/2399