Notice (2018-05-24): bugzilla.xamarin.com is now in
Please join us on
Visual Studio Developer Community and in the
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
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.
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.
Xamarin Studio: 6.2 (build 1821)
Created attachment 23789 [details]
Created attachment 23790 [details]
OSXFUSE Loopback sample
LoopbackFS.zip is the Objective-C loopback sample provided by OSXFUSE.
Created attachment 23791 [details]
OSXFUSE Binding Library Project
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.
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).