OSXFUSE crash after setting extended attributes

63 views
Skip to first unread message

Brad Medinger

unread,
Feb 21, 2017, 2:34:41 PM2/21/17
to OSXFUSE
We are using OSXFUSE in a Xamarin project for Mac to allow users to use native tools to work with a remote file system.  Our issue is that every time an extended attribute is set on a file, the entire application crashes.  We can consistently recreate this and have multiple crash logs, but haven't been able to track down why it is crashing.  

The easiest way for us to recreate this is to set a tag on a file from the Finder, which calls the setExtendedAttribute:ofItemAtPath:value:position:options:error: method on our file system delegate.  We add the extended attribute to an internal cache of our remote file system and return true.  Immediately after this is when the application crashes.  We've enabled the 'debug' option on OSXFUSE and can see there are no other method calls that are logged before the crash.

If we use the 'auto_xattr' option, everything works but uses the Apple Double files which we want to avoid using.

I’m not very familiar with reading these crash logs, but here is what I think is the relevant information from the crash:

Process:               MyApp [712]
Path:                  /Users/USER/*/MyApp.app/Contents/MacOS/MyApp
Identifier:            com.example.MyApp
Version:               1.0.2 (1)
Code Type:             X86-64 (Native)
Parent Process:        ??? [1]
Responsible:           MyApp [712]

Date/Time:             2017-02-13 16:15:28.870 -0600
OS Version:            Mac OS X 10.12.3 (16D32)
Report Version:        12


Time Awake Since Boot: 3400 seconds

System Integrity Protection: enabled

Crashed Thread:        8  tid_c507

Exception Type:        EXC_BAD_ACCESS (SIGABRT)
Exception Codes:       EXC_I386_GPFLT
Exception Note:        EXC_CORPSE_NOTIFY

External Modification Warnings:
Debugger attached to process.

Application Specific Information:
abort() called

Thread 8 Crashed:: tid_c507
0   libsystem_kernel.dylib             0x00007fffe8313dd6 __pthread_kill + 10
1   libsystem_pthread.dylib         0x00007fffe83ff787 pthread_kill + 90
2   libsystem_c.dylib                      0x00007fffe8279420 abort + 129
3   com.example.MyApp              0x000000010b2bbf52 mono_handle_native_sigsegv + 578 (mini-exceptions.c:2341)
4   com.example.MyApp              0x000000010b22d4fa mono_arch_handle_altstack_exception + 90 (exceptions-amd64.c:821)
5   com.example.MyApp              0x000000010b2c7eb8 mono_sigsegv_signal_handler + 440 (mini-runtime.c:2906)
6   libsystem_platform.dylib        0x00007fffe83f2bba _sigtramp + 26
7   ???                                000000000000000000 0 + 0
8   com.example.MyApp              0x000000010b1cdafd xamarin_arch_trampoline + 189 (trampolines-x86_64.m:518)
9   com.example.MyApp              0x000000010b1cee41 xamarin_x86_64_common_trampoline + 110 (trampolines-x86_64-asm.s:59)
10  com.github.osxfuse.frameworks.OSXFUSE     0x000000010b7ceda9 0x10b7c8000 + 28073
11  libosxfuse.2.dylib                     0x000000010e530a34 fuse_fs_setxattr + 160
12  libosxfuse.2.dylib                     0x000000010e545499 0x10e52f000 + 91289
13  libosxfuse.2.dylib                     0x000000010e530a34 fuse_fs_setxattr + 160
14  libosxfuse.2.dylib                     0x000000010e537a11 0x10e52f000 + 35345
15  libosxfuse.2.dylib                     0x000000010e53b60e 0x10e52f000 + 50702
16  libosxfuse.2.dylib                     0x000000010e53d741 0x10e52f000 + 59201
17  libosxfuse.2.dylib                     0x000000010e53efc0 fuse_session_process_buf + 22
18  libosxfuse.2.dylib                     0x000000010e539d89 fuse_session_loop + 202
19  libosxfuse.2.dylib                     0x000000010e535a6d fuse_loop + 523
20  libosxfuse.2.dylib                     0x000000010e540901 0x10e52f000 + 71937
21  libosxfuse.2.dylib                     0x000000010e540949 fuse_main_real + 15
22  com.github.osxfuse.frameworks.OSXFUSE     0x000000010b7ce9de 0x10b7c8000 + 27102
23  com.apple.Foundation          0x00007fffd46b2c6d __NSThread__start__ + 1243
24  libsystem_pthread.dylib       0x00007fffe83fcaab _pthread_body + 180
25  libsystem_pthread.dylib       0x00007fffe83fc9f7 _pthread_start + 286
26  libsystem_pthread.dylib       0x00007fffe83fc1fd thread_start + 13

Please let me know what other information would help in debugging why OSXFUSE is crashing.

Thanks,
Brad

Marc Miller

unread,
Feb 21, 2017, 2:55:18 PM2/21/17
to osxfus...@googlegroups.com
Are you sure this isn't just a crash in your application code?  These cross-language call stacks can be confusing, but it looks like Frame 7 is managed code since it's the one after the trampoline and the higher frames look like a transition (a so-called "trampoline").  If that's true then the crash is happening somewhere in there, which is consistent with everything working when you do auto_xattr.  I'm not familiar with Xamarin but if you can step through your xattr callback to make sure it actually gets called that should help you narrow things down.  Also, if you don't already have a unit testing framework to run the fuse callbacks outside of fuse that might be worth your while to set up.


--
You received this message because you are subscribed to the Google Groups "OSXFUSE" group.
To unsubscribe from this group and stop receiving emails from it, send an email to osxfuse-group+unsubscribe@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Sam Moffatt

unread,
Feb 21, 2017, 10:28:59 PM2/21/17
to osxfus...@googlegroups.com
I’m with Marc here, it looks like your app is triggering some sort of a segfault based on the back trace. Without seeing what your code does it’s hard to figure out what’s going on but it’s possible you’re trying to read something inappropriately and the OS is dinging you for it.

Have you been able to reproduce this using the loopback filesystem? Have you tried an empty implementation that just returns false?


Brad Medinger

unread,
Feb 24, 2017, 5:12:34 PM2/24/17
to OSXFUSE
I'm able to debug through my SetExtendedAttribute method on the file system delegate and that isn't throwing any errors, but I can't continue to step through Xamarin's code.  I tried changing this method so it doesn't do anything except return false, but still got the same application crash.  I haven't tried the loopback filesystem yet.

The output from Xamarin Studio actually shows a little more information than the crash log does.  Here is the stack of the crashed thread from the Xamarin Application Output:

thread #14: tid = 0x1e213, 0x00007fffc93ce482 libsystem_kernel.dylib`__wait4 + 10, name = 'tid_c607'
    frame #0: 0x00007fffc93ce482 libsystem_kernel.dylib`__wait4 + 10
    frame #1: 0x0000000102dbbc51 MyApp`mono_handle_native_sigsegv(signal=<unavailable>, ctx=<unavailable>, info=<unavailable>) + 433 at mini-exceptions.c:2348 [opt]
    frame #2: 0x0000000102d2d28a MyApp`mono_arch_handle_altstack_exception(sigctx=0x000000010e678f48, siginfo=<unavailable>, fault_addr=<unavailable>, stack_ovf=0) + 90 at exceptions-amd64.c:808 [opt]
    frame #3: 0x0000000102dc7c48 MyApp`mono_sigsegv_signal_handler(_dummy=<unavailable>, _info=<unavailable>, context=<unavailable>) + 440 at mini-runtime.c:2888 [opt]
    frame #4: 0x00007fffc94acbba libsystem_platform.dylib`_sigtramp + 26
    frame #5: 0x0000000102cccebb MyApp`::xamarin_invoke_trampoline(type=Tramp_Default, self=0x0000618000017760, sel="setExtendedAttribute:ofItemAtPath:value:position:options:error:", iterator=(MyApp`param_iter_next(void*, char const*, unsigned long, void*) at trampolines-x86_64.m:235), marshal_return_value=(MyApp`marshal_return_value(void*, char const*, unsigned long, void*, _MonoType*, bool, _MonoMethod*) at trampolines-x86_64.m:295), context=0x000070000a031ac8) + 5691 at trampolines-invoke.m:391
    frame #6: 0x0000000102ccd88d MyApp`::xamarin_arch_trampoline(state=0x000070000a031b10) + 189 at trampolines-x86_64.m:516
    frame #7: 0x0000000102ccebd1 MyApp`xamarin_x86_64_common_trampoline + 110
    frame #8: 0x0000000106a0dda9 OSXFUSE`___lldb_unnamed_symbol109$$OSXFUSE + 253
    frame #9: 0x0000000106a21a34 libosxfuse.2.dylib`fuse_fs_setxattr + 160
    frame #10: 0x0000000106a36499 libosxfuse.2.dylib`___lldb_unnamed_symbol376$$libosxfuse.2.dylib + 243
    frame #11: 0x0000000106a21a34 libosxfuse.2.dylib`fuse_fs_setxattr + 160
    frame #12: 0x0000000106a28a11 libosxfuse.2.dylib`___lldb_unnamed_symbol101$$libosxfuse.2.dylib + 182
    frame #13: 0x0000000106a2c60e libosxfuse.2.dylib`___lldb_unnamed_symbol162$$libosxfuse.2.dylib + 81
    frame #14: 0x0000000106a2e741 libosxfuse.2.dylib`___lldb_unnamed_symbol199$$libosxfuse.2.dylib + 1754
    frame #15: 0x0000000106a2ffc0 libosxfuse.2.dylib`fuse_session_process_buf + 22
    frame #16: 0x0000000106a2ad89 libosxfuse.2.dylib`fuse_session_loop + 202
    frame #17: 0x0000000106a26a6d libosxfuse.2.dylib`fuse_loop + 523
    frame #18: 0x0000000106a31901 libosxfuse.2.dylib`___lldb_unnamed_symbol240$$libosxfuse.2.dylib + 82
    frame #19: 0x0000000106a31949 libosxfuse.2.dylib`fuse_main_real + 15
    frame #20: 0x0000000106a0d9de OSXFUSE`___lldb_unnamed_symbol107$$OSXFUSE + 1732
    frame #21: 0x00007fffb576cc6d Foundation`__NSThread__start__ + 1243
    frame #22: 0x00007fffc94b6aab libsystem_pthread.dylib`_pthread_body + 180
    frame #23: 0x00007fffc94b69f7 libsystem_pthread.dylib`_pthread_start + 286
    frame #24: 0x00007fffc94b61fd libsystem_pthread.dylib`thread_start + 13

If I'm reading this correctly, xamarin_invoke_trampoline would be where the error is occurring right?  If so, then maybe this is an issue with Xamarin and not OSXFUSE.

Thanks,
Brad
To unsubscribe from this group and stop receiving emails from it, send an email to osxfuse-grou...@googlegroups.com.

For more options, visit https://groups.google.com/d/optout.

--
You received this message because you are subscribed to the Google Groups "OSXFUSE" group.
To unsubscribe from this group and stop receiving emails from it, send an email to osxfuse-grou...@googlegroups.com.

Sam Moffatt

unread,
Feb 24, 2017, 7:24:49 PM2/24/17
to osxfus...@googlegroups.com
To confirm I understand, you can see that your method is hit but after it returns it bounces to the exception?
To unsubscribe from this group and stop receiving emails from it, send an email to osxfuse-group+unsubscribe@googlegroups.com.

Brad Medinger

unread,
Feb 27, 2017, 9:09:30 AM2/27/17
to OSXFUSE
Correct.

Sam Moffatt

unread,
Feb 27, 2017, 11:09:51 AM2/27/17
to osxfus...@googlegroups.com
Definitely sounds like a bug in Mono somewhere or something it isn't handling properly from the Objective-C API implementation. Seems odd that it'd happen after the method completed though. Perhaps see if you can get them to investigate? Not to rule out that OSXFUSE might be doing something odd in terms of what Mono is expecting but to steer any investigation should they figure something out :)

Cheers,

Sam 

--
Sam Moffatt

Note: I'm not at my desk, responses may be delayed. Apologies for the typos, smartphones aren't all that smart. 

Reply all
Reply to author
Forward
0 new messages