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
GitHub or Developer Community 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.
Created attachment 7026 [details]
OSXFUSE binding: EXC_BAD_ACCESS during GC_delete_gc_thread for Boehm, but not SGen
## Steps to reproduce
1. Install the "FUSE for OS X" framework .
>  http://osxfuse.github.io/
2. Build the attached test project in the Debug configuration. The project is nearly a line-by-line translation of . The minimal `ApiDefinition.cs` and compiled binding for OSXFUSE are in the `lib/` subfolder.
>  https://github.com/osxfuse/filesystems/tree/master/filesystems-objc/HelloFS
3. Run the app, attach to it with `lldb`, and continue execution. When the app has finished launching, a new "HelloFS" FUSE volume will appear in Finder.
4. Quit the application. This calls the `fs.Unmount()` method.
5. When `lldb` breaks on the EXC_BAD_ACCESS, run `bt`.
> * thread #5: tid = 0xeb335, 0x0023d68a OSXFuseTest`GC_pthread_join [inlined] GC_delete_gc_thread(gc_id=0x00000000) + 35 at pthread_support.c:826, stop reason = EXC_BAD_ACCESS (code=2, address=0x0)
> * frame #0: 0x0023d68a OSXFuseTest`GC_pthread_join [inlined] GC_delete_gc_thread(gc_id=0x00000000) + 35 at pthread_support.c:826
> frame #1: 0x0023d667 OSXFuseTest`GC_pthread_join(thread=0xb0523000, retval=0x00000000) + 231 at pthread_support.c:1360
> frame #2: 0x001d8429 OSXFuseTest`mono_threads_join_threads + 57 at threads.c:4765
> frame #3: 0x0013d18a OSXFuseTest`finalizer_thread(unused=0x00000000) + 538 at gc.c:1104
> frame #4: 0x001ddd14 OSXFuseTest`start_wrapper [inlined] start_wrapper_internal(data=0x0074a830) + 442 at threads.c:647
> frame #5: 0x001ddb5a OSXFuseTest`start_wrapper(data=0x0074a830) + 26 at threads.c:692
> frame #6: 0x0021bb9d OSXFuseTest`inner_start_thread(arg=0xbffff750) + 253 at mono-threads-posix.c:94
> frame #7: 0x0023dfad OSXFuseTest`GC_start_routine(arg=0x01ee0f60) + 93 at pthread_support.c:1502
> frame #8: 0x95e7d5fb libsystem_pthread.dylib`_pthread_body + 144
> frame #9: 0x95e7d485 libsystem_pthread.dylib`_pthread_start + 130
## Avoid the crash by removing the `contentsAtPath:` selector.
The `[Export ("contentsAtPath:")]` line in `HelloFuseFileSystem` is required to produce the error. Removing this line avoids the problem.
## "Workaround" by using SGen
Check ON "Project Options -> Mac OS X Packaging -> Use the SGen Garbage Collector". (This also requires that "Include the Mono runtime in the application bundle" be checked ON.)
## Additional information
The Objective-C OSXFUSE wrapper library can be found here:
I tried a few little experiments with this. I found that performing the actual FUSE mount via the call to `fuse_main()` in `GMUserFileSystem.m` _is_ required to get the crash. Calling the delegate's `contentsOfDirectoryAtPath:error:` and `contentsAtPath:` selectors in `[GMUserFileSystem mountAtPath:withOptions:]` is not sufficient.
## Version information
Xamarin Studio 5.0 (build 878)
Mono 3.4.0 ((no/c3fc3ba)
Xcode 5.1 (5084), Build 5B130a
Mac OS X 10.9.3
This looks like a dup of:
*** This bug has been marked as a duplicate of bug 19343 ***