Bug 51263 - Application crash when using CFMessagePort
Summary: Application crash when using CFMessagePort
Alias: None
Product: Xamarin.Mac
Classification: Desktop
Component: Library (Xamarin.Mac.dll) ()
Version: 3.0.0 (C9)
Hardware: Macintosh Mac OS
: --- normal
Target Milestone: 15.6
Assignee: Bugzilla
Depends on:
Reported: 2017-01-06 08:55 UTC by Denys
Modified: 2017-09-25 14:29 UTC (History)
3 users (show)

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

sample projects (692.14 KB, application/x-zip-compressed)
2017-01-06 08:55 UTC, Denys
crash report (91.82 KB, text/plain)
2017-01-06 09:05 UTC, Denys

Notice (2018-05-24): bugzilla.xamarin.com is now in read-only mode.

Please join us on Visual Studio Developer Community and in the Xamarin and 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 Links.

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.

Related Links:

Description Denys 2017-01-06 08:55:16 UTC
Created attachment 19111 [details]
sample projects
Comment 1 Denys 2017-01-06 09:03:25 UTC
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

Comment 2 Denys 2017-01-06 09:05:24 UTC
Created attachment 19112 [details]
crash report
Comment 3 Alex Soto [MSFT] 2017-01-07 05:09:29 UTC
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).
Comment 4 Denys 2017-01-07 18:22:16 UTC
=== 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 ===

Not Installed

=== Xamarin Inspector ===

Hash: ebe1a22
Branch: master
Build date: Tue, 20 Dec 2016 16:38:02 GMT

=== Xamarin.Android ===

Version: (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 ===

Not Installed

=== Apple Developer Tools ===

Xcode 8.1 (11544)
Build 8B62

=== Xamarin.Mac ===

Version: (Xamarin Studio Community)

=== Xamarin.iOS ===

Version: (Xamarin Studio Community)
Hash: 6a925ff
Branch: master
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
    root:xnu-3789.31.2~1/RELEASE_X86_64 x86_64
Comment 5 Denys 2017-05-31 07:00:21 UTC
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?
Comment 6 Alex Soto [MSFT] 2017-05-31 15:34:00 UTC
Per Chris request, assigned.
Comment 7 Chris Hamons 2017-05-31 15:41:57 UTC
@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.

Comment 8 Chris Hamons 2017-09-22 20:09:56 UTC
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
Comment 9 Chris Hamons 2017-09-22 20:12:34 UTC
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).
Comment 11 Chris Hamons 2017-09-25 14:29:56 UTC
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.