iOS SDK sometimes crashes or deadlocks in cxrDestroyReceiver

We’ve integrated the iOS CloudXR SDK with our Zapbox runtime as described in this post.

The app currently generally works quite well. However there are some crashes and deadlocks when calling cxrDestroyReceiver in certain states that means we can’t provide a polished user experience that automatically reconnects if the connection is dropped.

The easiest one to reproduce is to enter an incorrect IP and attempt to connect, but then call cxrDestroyReceiver before the connection attempt times out. This ends up with an EXC_BAD_ACCESS in a netStreamClient function (the stack is interesting as it’s still within the call to connect - not sure if that is the unexpected condition here)

I’ve also seen times when the stream just drops out and a log reports that the streamer is disconnected but the status callback is never called. In this case calling cxrDestroyReceiver looks to deadlock on some mutex. As a guess, perhaps the network thread is blocking on a read that will never come and needs to be sent a signal to correctly respond to the disconnection request.

Whatever the underlying cause, this makes clean recovery impossible and requires killing the app and restarting. I tried just leaving the old receiver dangling and creating a new one but the SDK didn’t allow that either.

I’d appreciate any efforts from NVIDIA to resolve these issues in the proprietary parts of CloudXR as they do have a significant impact on the user experience of our client. Thanks!

Thanks for the note. We’re unable to provide timelines or insight into resolution, but can pass this along for future updates.