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.
Sometimes a app crashes silently, sometimes after unlock mac os.
Process: *** 
Code Type: X86 (Native)
Parent Process: ??? 
Responsible: *** 
User ID: 501
Date/Time: 2017-04-27 10:09:11.362 +0300
OS Version: Mac OS X 10.11.5 (15F34)
Report Version: 11
Anonymous UUID: 6727C7F3-5213-97BC-88D9-4262A4B97E3D
Sleep/Wake UUID: A2D1D119-844A-4175-8BE8-71FD5BD53CD9
Time Awake Since Boot: 3000 seconds
System Integrity Protection: disabled
Crashed Thread: 3 tid_2303
Exception Type: EXC_BREAKPOINT (SIGTRAP)
Exception Codes: 0x0000000000000002, 0x0000000000000000
Exception Note: EXC_CORPSE_NOTIFY
Application Specific Information:
*** CFRelease() called with NULL ***
Thread 3 Crashed:: tid_2303
0 com.apple.CoreFoundation 0x9878850a CFRelease + 2042
1 ??? 0x0d858728 0 + 226854696
2 ??? 0x0d858518 0 + 226854168
3 ??? 0x0d858454 0 + 226853972
4 ??? 0x0d837fe3 0 + 226721763
5 ??? 0x0d858224 0 + 226853412
6 ??? 0x0d858118 0 + 226853144
7 ??? 0x0a3a571d 0 + 171595549
8 libmono-2.0.dylib 0x005973f8 mono_gc_run_finalize + 1032 (gc.c:258)
9 libmono-2.0.dylib 0x005d2159 sgen_client_run_finalize + 25 (sgen-mono.c:493)
10 libmono-2.0.dylib 0x005e1669 sgen_gc_invoke_finalizers + 73 (sgen-gc.c:2469)
11 libmono-2.0.dylib 0x00598874 finalizer_thread + 612 (gc.c:741)
12 libmono-2.0.dylib 0x005714f9 start_wrapper + 569 (threads.c:717)
13 libmono-2.0.dylib 0x0062c1ad inner_start_thread + 349 (mono-threads-posix.c:92)
14 libsystem_pthread.dylib 0x9760a780 _pthread_body + 138
15 libsystem_pthread.dylib 0x9760a6f6 _pthread_start + 155
16 libsystem_pthread.dylib 0x97607f7a thread_start + 34
Unfortunately a simple stack trace is far from enough to diagnose this issue. A random stack trace does not show what the problem is, nor does it show that the problem is in Xamarin.Mac and not your application. If you are looking for assistance the forums (https://forums.xamarin.com/categories/mac) or stack overflow are more appropriate unless you pin down an actual defect in Xamarin.Mac.
It appears we are running a finalizer, and something is trying to CFRelease (NULL). It is difficult to know if this is a bug in our code, an Apple API which was used incorrectly that is crashing, or something else entirely.
A sample reproducing this issue would be ideal for you to get started.
You could also try running your application under Apple's Instruments tool and look for zombies. This is an iOS guide but the idea holds (https://developer.xamarin.com/guides/ios/deployment,_testing,_and_metrics/walkthrough_Apples_instrument/)
You could also try using Xamarin.Mac 3.2 and Ahead of Time compilation to get better stack traces (https://developer.xamarin.com/releases/mac/xamarin.mac_3/xamarin.mac_3.2/#Ahead_of_Time_Compilation_Experimental).
I don`t use apple api, only managed code, I have a big application, and many Dispose() calls, how I can call Dispose for null-object, where have been a null reference exception first.
In Xamarin.Mac (and Xamarin.iOS) application, each C# object that represents a native type, such as NSView contains a native handle to the native object we are manipulating.
CFRelease is referring to that native handle, not the managed c# object.
One example that come to mind is if you have a Cocoa object that expects to call back with some information and you (either directly or via the GC) dispose of it before the callback occurs you will crash when native Cocoa tries to call your object.
I'm not suggesting that is your issue, but it is one example where a programming error can cause crashes similar to this.
I would suggest looking into using Instruments to track down your issue or bisecting your use case until you can find a reproducible sample to dig into.