Bug 20502 - OSXFUSE binding: EXC_BAD_ACCESS during GC_delete_gc_thread for Boehm, but not SGen
Summary: OSXFUSE binding: EXC_BAD_ACCESS during GC_delete_gc_thread for Boehm, but not...
Status: RESOLVED DUPLICATE of bug 19343
Alias: None
Product: Runtime
Classification: Mono
Component: GC (show other bugs)
Version: 3.4.0
Hardware: PC Mac OS
: --- normal
Target Milestone: ---
Assignee: Bugzilla
Depends on:
Reported: 2014-06-10 00:18 UTC by Brendan Zagaeski (Xamarin Team, assistant)
Modified: 2015-01-08 05:55 UTC (History)
4 users (show)

See Also:
Is this bug a regression?: ---
Last known good build:

Test case (12.49 KB, application/zip)
2014-06-10 00:18 UTC, Brendan Zagaeski (Xamarin Team, assistant)

Description Brendan Zagaeski (Xamarin Team, assistant) 2014-06-10 00:18:12 UTC
Created attachment 7026 [details]
Test case

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 [1].
> [1] http://osxfuse.github.io/

2. Build the attached test project in the Debug configuration. The project is nearly a line-by-line translation of [2]. The minimal `ApiDefinition.cs` and compiled binding for OSXFUSE are in the `lib/` subfolder.
> [2] 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`.

## Result

> * 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:
> https://github.com/osxfuse/framework

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

osxfuse 2.6.4

Xamarin Studio 5.0 (build 878)
Mono 3.4.0 ((no/c3fc3ba)

Xcode 5.1 (5084), Build 5B130a


Mac OS X 10.9.3
Comment 2 Zoltan Varga 2014-06-10 13:55:05 UTC
This looks like a dup of:
Comment 3 Zoltan Varga 2015-01-08 05:55:05 UTC

*** This bug has been marked as a duplicate of bug 19343 ***

Note You need to log in before you can comment on or make changes to this bug.