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.
In Mac OS X Sierra, NSLog() is now a wrapper for a new function called os_log(). os_log(), and therefore NSLog(), take a snapshot of the stack at the time they are recorded. For some reason, Apple's stack snapshot function crashes when NSLog() or os_log() is called from mono JIT. A SIGSEGV occurs inside of a function named os_trace_location_for_address(). The stack looks like
[Mono sigsegv handler]
frame #5: 0x9f755ebb libsystem_platform.dylib`_sigtramp + 43
frame #6: 0x9f77f564 libsystem_trace.dylib`_os_trace_location_for_address + 31
frame #7: 0x9f78a3d8 libsystem_trace.dylib`_os_log_actual + 90
frame #8: 0x9f78c41a libsystem_trace.dylib`os_log_with_args + 976
frame #9: 0x9f78c64e libsystem_trace.dylib`os_log_shim_with_CFString + 168
frame #10: 0x945bea74 CoreFoundation`_CFLogvEx3 + 148
frame #11: 0x95ca6450 Foundation`_NSLogv + 109
frame #12: 0x95c924cb Foundation`NSLog + 26
frame #13: 0x00458544
[More JIT frames]
There does not appear to be any way to opt out of os_log's stack snapshotting. We do not currently know why os_log's stack snapshotting is crashing, so we do not know if it is in principle possible to change our stacks to make os_log not crash.
It is possible to avoid the crash by doing "full AOT" (ie the mono option of compiling C# bytecode entirely to machine code) on your Mac application.
It is possible to avoid the crash by having the immediate frame that calls NSLog be a C frame. If you write a C wrapper, have the C wrapper call NSLog, and then call your C wrapper from JIT C# code, there is no crash.
The crash does not occur on iOS, *either* the simulator *or* the device, even though on the iOS simulator the JIT is running, even though os_log is present in iOS 10.
We have reported the bug to Apple (there is a "radar") and they are aware of it. We are waiting for feedback on whether Apple will fix this in a future update, or whether we can or should work around it on the Mono side. Our understanding is that the bug will *not* be fixed for the time of Sierra release. Sierra has already gone to GM.
The upshot is that when Sierra is released, any existing OS X application which is built on Mono and which calls NSLog using P/Invoke will crash. Our suggested workaround from our current release notes is that if you need to work on Sierra, you should update your application to
1. Use System.Console.WriteLine instead of NSLog directly
2. Create a small C static library which invokes NSLog for you, link it into your application, and invoke it instead.
We will update as soon as we know what the long term fix will be.
*** Bug 43541 has been marked as a duplicate of this bug. ***
Created attachment 17590 [details]
Created attachment 17591 [details]
XCode run environment
This has been fixed in the 10.12.4 betas: https://microsoft-my.sharepoint.com/personal/tirisi_microsoft_com/_layouts/15/guestaccess.aspx?guestaccesstoken=+XtZYpsUkq0Q1MGpfcTEzXEMHNxoTvQwN8OmTALV8zM=&docid=2_1084e3d75896b4de8b48bef875cb35ea5&rev=1
Apple fixed this, closing.