|Summary:||Xamarin.Mac crash when returning to native code of a binding library|
|Component:||Runtime||Assignee:||Rolf Bjarne Kvinge [MSFT] <rolf>|
|Severity:||normal||CC:||chris.hamons, mono-bugs+monomac, rolf|
|Tags:||Is this bug a regression?:||No|
|Last known good build:|
OSXFUSE Loopback sample
OSXFUSE Binding Library Project
Xamarin.Mac Loopback Sample
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 Xamarin.Mac: 184.108.40.206 Xcode: 8.3.3 MacOS: 10.12.5
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
Comment 8 Rolf Bjarne Kvinge [MSFT] 2017-08-02 12:04:20 UTC