Multipeer Connectivity crash when inviting peer that stopped advertising

Question

I have the following scenario:

• Peer A is waiting for invitations in a custom UI (let's call it WaitingVC). The MCNearbyServiceAdvertiser object is initialized at application start, and the advertising starts (startAdvertisingPeer) when the WaitingVC is presented.
• Peer B has the MCNearbyServiceBrowser up and running, also with custom UI (that is, not using the Apple provided MCBrowserViewController).
• Peer B finds Peer A (browser:foundPeer:withDiscoveryInfo: is called).
• Meanwhile Peer A chooses to close the WaitingVC. Advertising is stopped (stopAdvertisingPeer).
• There is a few seconds lag, before Peer B finds out, that Peer A is lost (that is, browser:lostPeer: is called).
• If in these few seconds, Peer B chooses to invite Peer A (who still seems to be available for Peer B), Peer A crashes (yes, the invited one, who normally stopped advertising).
• Peer B's invite normally times out, and no problem arises.

The crash happens in queue com.apple.NSNetServices.tcplistener-queue. A dispatch_call_block_and_release call fails at release (EXC_BREAKPOINT).

I truly wonder, if this a bug in the MC framework; or am I missing some cleanup procedure? Peer A only does the following:

• App delegate: Creating an MCPeerID, store in a strong property,
• App delegate: Creating an MCNearbyServiceAdvertiser, store in a strong property, setting delegate,
• In WaitingVC: calling startAdvertisingPeer, then calling stopAdvertisingPeer when done.

The crash seemingly occurs no matter what I do. If the MCNearbyServiceAdvertiser object and the MCPeerID object is being kept in WaitingVC and thus destroyed after the WaitingVC is closed, the crash still happens.

Apart from this, everything works fine (invitation procedure, connecting, exchanging data); but this few seconds window for certain failure is not really acceptable. Keeping the advertiser running all the time solves this, but it's just treating the symtpom (and this "sync" feature would be used seldom in the applicaiton, so it's also an overkill).

Update:

The same crash happens when using MCAdvertiserAssistant, if I call its stop method on Peer A, and quickly connect on Peer B. Also, I tested the scenario on this tutorial: http://techmaster.vn/2013/09/multipeer-connectivity-quick-tutorial/ - and the result is the same: Crash. So I have a strong suspicion, this is a bug on Apple's side...

Answer 1

I found a simple workaround. I added a delay before starting the browser going.

To fill in the whole story I created a wrapper to replace GKSession with MCSession. The connection was being closed and reopened under specific circumstances, by both ends at the same time, hence it crashed. Adding a delay to the browser start offset it from the tear down of the other end avoiding the problem.

Answer 2

I've been experiencing the same crash and according to this thread in the Dev Forums so have other people. A bug report has been created for it:

Developer Forums: Multipeer Connectivity Crash

Answer 3

This looks like a problem with your delegate callback

advertiser:didReceiveInvitationFromPeer:withContext:invitationHandler:

most likely with the final argument, the invitationHandler block. Is this method being called? When B makes A crash, there must be something that is being called and this seems to be the only conceivable entry point.