8000 iOS vs. Firefox compatibility problem? EXC_BAD_ACCESS crash · Issue #855 · flutter-webrtc/flutter-webrtc · GitHub
[go: up one dir, main page]

Skip to content

iOS vs. Firefox compatibility problem? EXC_BAD_ACCESS crash #855

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Closed
jakobleck opened this issue Feb 14, 2022 · 2 comments
Closed

iOS vs. Firefox compatibility problem? EXC_BAD_ACCESS crash #855

jakobleck opened this issue Feb 14, 2022 · 2 comments

Comments

@jakobleck
Copy link
jakobleck commented Feb 14, 2022

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)

@jakobleck
Copy link
Author

Ok, I've done some digging:
The issue is reproducible in the flutter-webrtc-demo project, I ran it under Flutter stable 2.8.1, with an iOS 14.7.1 device connected to Firefox 97.0 in the same local network using flutter-webrtc-server.

My best guess would be that there is something wrong with the CocoaPod/the iOS build or how the flutter project communicates with it.

To narrow it down, I've tested it with several versions of the flutter_webrtc package, each time after changing pubspec I ran

flutter clean
flutter pub get  
pod update flutter_webrtc

(here, for example, after setting to 0.6.10+hotfix.1)

➜  ios git:(master) ✗ pod update flutter_webrtc
Updating local specs repositories
Analyzing dependencies
Downloading dependencies
Installing Flutter (1.0.0)
Installing Libyuv (1703)
Installing WebRTC-SDK (92.4515.07)
Installing flutter_webrtc (0.2.2)
Installing path_provider_ios (0.0.1)
Installing shared_preferences (0.0.1)
Generating Pods project
Integrating client project
Pod installation complete! There are 4 dependencies from the Podfile and 6 total pods installed.
➜  ios git:(master) ✗ 

I've been through most versions of the package from 0.6.8 on and it seems that 0.6.10+hotfix.1 is the last one to not have the error reported here. 0.7.0 does have it.

If one of the helping hands maitaining this package needs further information, I'm happy to provide it where I can. :)

@jakobleck
Copy link
Author

Fixed in 0.8.3 (with native build version 97.x): The failure trying to add an IceCandidate no longer yields a bad access and app crash, but a PlatformException that can be caught. :)

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

1 participant
0