Aborting after deadlock

[lukeadamson]

Hey @stasel, I'm seeing a crash in my app that uses the WebRTC package, and I can reproduce that same crash in your demo app (WebRTC-iOS). I'm wondering if you've seen it before or have any idea what might be causing it:

The demo app is crashing in the iOS Simulator after logging:

SetProperty: RPC timeout. Apparently deadlocked. Aborting now.

Here are my repro steps:

1. Launch the signaling server (I'm just testing with your Swift signaling server on my local system).
2. Update the demo project with the IP address of the signaling server.
3. Build and run the demo app on the iOS Simulator (Xcode 15, iOS 17, macOS 14).
4. Build and run the demo app on an iOS device (in my case, an iPhone 12 Pro running iOS 17).
5. Tap "Send offer" on the app running on the device.
6. Tap "Send answer" on the app running on the iOS Simulator.

After several seconds... the app on the Sim will log the above error about a deadlock and crash. Here's a screenshot of the crash, showing abort being called from one of the threads:

Sadly, I can't reproduce this reliably in your demo app (though it's happening very reliably for me in my real app). I thought it was 100% reproducible in the demo, but then it just started working on fine and continued to do so after several re-launches and re-attempts at crashing it.

Both the "...Apparently deadlocked" message and the intermittent nature of the crash give it a strong smell of a multithreading bug.

Any ideas?

[lukeadamson]

Some added info:

When I reproduce the crash in my app, I notice that the call to peerConnection.setLocalDescription(_:) basically hangs (the callback is not called before the error message about the deadlock and the call to abort kills the app).

When executed on an iOS device (as opposed to the iOS Simulator), the call to setLocalDescription(_:) calls its callback as expected and it works more or less fine.

[lukeadamson]

A little more info... now I've determined that it "sometimes" works on the iOS Simulator. It's definitely inconsistent.

[jbruckne]

Hey @lukeadamson, I'm running into the same issue when using a simulator to test with webRTC. The root cause seems to be something with webRTC's audio handling. A couple of my findings:

• The last call to webRTC is to PeerConnection.add(RTCIceCandidate), after the offer/answer negotiation. This is the last point before the connection is 'complete' and data sharing starts.
• It only happens if the audio track is configured. If only data channels are configured, the connection succeeds and messages can be sent back and forth.
• This stack overflow post may be relevant. It mentioned how the default audio I/O settings were leading to a crash on the simulator when using AVAudioPlayer. I assume webRTC is using some of the same underlying AVAudioEngine stuff. Switching I/O settings didn't immediately fix it, but I have since been able to get it to work.

I won't be able to provide much help with debugging the root cause within the webRTC library itself, but hopefully this helps you work around the issue.

@stasel Do you have experience debugging the internals of webRTC or primarily just maintaining the distribution?

[fwaris]

For what it's worth, I was running into a similar issue. I am using audio + data channel only (no video).
I added code to activate (and later release) the AVAudioSession:

open AVFoundation
open Foundation
module internal RecordingSession =
    let checkError src f =
        let err : NSError = f()
        if err <> null then
            let msg = $"error with recording session. Src {src}; Error {err}"
            failwith msg                   
            
    let activate() =
        let sess = AVAudioSession.SharedInstance()
        checkError "activate:SetCategory" (fun () -> sess.SetCategory(AVAudioSessionCategory.Record))
        checkError "activate:SetActive" (fun () -> sess.SetActive(true))
            
    let release() =
        let sess = AVAudioSession.SharedInstance()
        checkError "release" (fun () -> sess.SetActive(false))

(.Net Maui F# environment - not Swift)

That seems to have fixed the 'abort after deadlock' issue.