Description
edit:TL;DR: Reproduction: Use flutter_webrtc ^0.7.0 in the demo program and during a p2p call wait for the browser side (Firefox) to send an ICE candidate and thereby crash the app (iOS). Usually took about 5-10 seconds when I tested.
Using flutter_webrtc 0.8.1, Flutter stable 2.8.1, and an iOS 14.7.1 device the following has repeatedly occured in a video call application I'm working on:
When connecting with a peer (always in a Web Interface written in js) that is using Chrome all is well, when the peer is using Firefox the app crashes (some time into the video session) with the following message:
* thread #1, queue = 'com.apple.main-thread', stop reason = EXC_BAD_ACCESS (code=1, address=0x0)
frame #0: 0x0000000101145c38 WebRTC`___lldb_unnamed_symbol3214$$WebRTC + 104
WebRTC`___lldb_unnamed_symbol3214$$WebRTC:
-> 0x101145c38 <+104>: ldr x8, [x0]
0x101145c3c <+108>: ldr x9, [x8, #0x10]
0x101145c40 <+112>: add x8, sp, #0x28 ; =0x28
0x101145c44 <+116>: blr x9
Target 0: (Runner) stopped.
Lost connection to device.
Apparently this is triggered when trying to add an IceCandidate to the PeerConnection (when the candidate has just been received from the remote peer). At the start of the session the connection is created and IceCandidates are added without a problem.
Any idea how to fix this?
What seems to work is downgrading (I used flutter_webrtc 0.6.8 in pubspec.yaml, Podfile.lock says 0.2.2), which of course is suboptimal. :) (Although it has the additional benefit of avoiding #831)