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.
Created attachment 19111 [details]
Xamarin.Mac appication with UI crashes when using CFMessagePort.
Steps to repruduce the issue:
- run server and client from the sample projects
- press button on the client to sent several messages via CFMessagePort to the server
- switch focus to the server window
- back to client and press the button again
Most cases the server crashes right after it receives the focus. Sometime you should return to the client and press the test button again.
Sample projects and crash report is attached
Created attachment 19112 [details]
I can reproduce this, could you please attach your version information?
The easiest way to get exact version information is to use the
"Xamarin Studio" menu, "About Xamarin Studio" item, "Show Details"
button and copy/paste the version informations (you can use the
"Copy Information" button).
=== Xamarin Studio Community ===
Version 6.2 (build 1701)
Installation UUID: 6a6eee5c-8f79-47d5-bc4a-c1b30575967b
Mono 4.8.0 (mono-4.8.0-branch/038ff4a) (64-bit)
GTK+ 2.24.23 (Raleigh theme)
Package version: 408000425
=== NuGet ===
=== Xamarin.Profiler ===
=== Xamarin Inspector ===
Build date: Tue, 20 Dec 2016 16:38:02 GMT
=== Xamarin.Android ===
Version: 184.108.40.206 (Xamarin Studio Community)
Android SDK: /Users/denys/Library/Developer/Xamarin/android-sdk-macosx
Supported Android versions:
6.0 (API level 23)
SDK Tools Version: 25.1.2
SDK Platform Tools Version: 24.0.0
SDK Build Tools Version: 23.0.2
Java SDK: /usr
java version "1.8.0_101"
Java(TM) SE Runtime Environment (build 1.8.0_101-b13)
Java HotSpot(TM) 64-Bit Server VM (build 25.101-b13, mixed mode)
Android Designer EPL code available here:
=== Xamarin Android Player ===
=== Apple Developer Tools ===
Xcode 8.1 (11544)
=== Xamarin.Mac ===
Version: 220.127.116.117 (Xamarin Studio Community)
=== Xamarin.iOS ===
Version: 10.4.0.67 (Xamarin Studio Community)
Build date: 2017-01-03 14:04:46-0500
=== Build Information ===
Release ID: 602001701
Git revision: f2922e7c22b4f206ee2d7683ca59701757f80da3
Build date: 2017-01-03 11:10:00-05
Xamarin addins: 3ea2e145863004103d37d20fc2c94fcd7bb6a1ce
Build lane: monodevelop-lion-cycle9
=== Operating System ===
Mac OS X 10.12.2
Darwin imacdev 16.3.0 Darwin Kernel Version 16.3.0
Thu Nov 17 20:23:58 PST 2016
Hi, guys. It's five moths passed... Any activity on this issue? If fixing the CFMessagePort is not your primary priority, can you suggest an alternative way use interprocess communications on MacOS?
Per Chris request, assigned.
@Denys - I understand your frustration. Xamarin.Mac has a non-trivial backlog of issues that we are working through, and not all issues are prioritized against other features/issues/support.
However, this issue should not have slipped by without some research.
Sorry for the long delay in digging into this.
There appears to be some lifetime bug in returning items from HandlePortCallBack. If you return null instead I can not get it to crash.
Storing a reference to the item doesn't see to do the trick.
This matches the stack trace data:
* frame #0: 0x00007fff998a6802 CoreFoundation`_CFRelease + 1346
frame #1: 0x0000000100b6e290
frame #2: 0x00007fff99879059 CoreFoundation`__CFMessagePortPerform + 873
frame #3: 0x00007fff997e3289 CoreFoundation`__CFRUNLOOP_IS_CALLING_OUT_TO_A_SOURCE1_PERFORM_FUNCTION__ + 41
and poking registers at the time of death strongly suggest an NSData:
(lldb) register read
General Purpose Registers:
rax = 0x00007fff99b23f59 "Detected over-release of a CFTypeRef"
rbx = 0x0000000100b6e290
rcx = 0x00007fffb4c68370 (void *)0x001dffffb4c68399
rdx = 0x00007fffaeafa900 libobjc.A.dylib`objc_debug_isa_class_mask
rdi = 0x0000000100b679d0
rsi = 0x0000000100b679d0
rbp = 0x00007fff5fbfc860
rsp = 0x00007fff5fbfc820
r8 = 0x0000000000000154
r9 = 0x0000000100b6e290
r10 = 0x0000000080000000
r11 = 0x00000000000018fc
r12 = 0x00007fff5fbfda20
r13 = 0x0000000100b12900
r14 = 0x0000000100b679d0
r15 = 0x0000000100b12900
rip = 0x00007fff998a6802 CoreFoundation`_CFRelease + 1346
rflags = 0x0000000000000206
cs = 0x000000000000002b
fs = 0x0000000000000000
gs = 0x0000000000000000
(lldb) po 0x00007fffb4c68370
I think this might be the problem:
Data to send back to the sender of the message. The system releases the returned CFData object. Return NULL if you want an empty reply returned to the sender.
We are not bumping the count before returning, so we think we own it _and_ the system does. It's a race to determine who releases it first (I bet we handle the system beating us better that vice versa).
Fixed in 15.6 timeframe.
If you want a terrible work around, you could call DangerousRetain on the item you are returning from your callback. That will "fix" it for now, but will cause a memory leak in 15.6 when you get the "real" fix.