flutter-webrtc icon indicating copy to clipboard operation
flutter-webrtc copied to clipboard

App crashes at the end of the call

Open solid-yuriiuvarov opened this issue 3 years ago • 18 comments

Describe the bug Sometimes, when the call ends, the application crashes.

Android log
[   +3 ms] I/flutter (10236): [2021-12-03 15:57:04.308] Level.debug rtc_session.dart:1246 ::: receiveRequest()
[ +170 ms] I/AudioTrack(10236): isLongTimeZoreData zoer date time 1 Seconds
[ +781 ms] I/org.webrtc.Logging(10236): CameraStatistics: Camera fps: 19.
[ +352 ms] I/org.webrtc.Logging(10236): EglBase14Impl: Using OpenGL ES version 2
[   +2 ms] E/org.webrtc.Logging(10236): SurfaceTextureHelper: decoder-texture-thread create failure
[        ] E/org.webrtc.Logging(10236): SurfaceTextureHelper: java.lang.RuntimeException: Failed to create EGL context: 0x3003
[        ] E/org.webrtc.Logging(10236): SurfaceTextureHelper: java.lang.RuntimeException: Failed to create EGL context: 0x3003
[        ] E/org.webrtc.Logging(10236): 	at org.webrtc.EglBase14Impl.createEglContext(EglBase14Impl.java:282)
[        ] E/org.webrtc.Logging(10236): 	at org.webrtc.EglBase14Impl.<init>(EglBase14Impl.java:78)
[        ] E/org.webrtc.Logging(10236): 	at org.webrtc.EglBase$-CC.createEgl14(EglBase.java:215)
[        ] E/org.webrtc.Logging(10236): 	at org.webrtc.EglBase$-CC.create(EglBase.java:158)
[        ] E/org.webrtc.Logging(10236): 	at org.webrtc.SurfaceTextureHelper.<init>(SurfaceTextureHelper.java:187)
[        ] E/org.webrtc.Logging(10236): 	at org.webrtc.SurfaceTextureHelper.<init>(SurfaceTextureHelper.java:33)
[        ] E/org.webrtc.Logging(10236): 	at org.webrtc.SurfaceTextureHelper$1.call(SurfaceTextureHelper.java:75)
[        ] E/org.webrtc.Logging(10236): 	at org.webrtc.SurfaceTextureHelper$1.call(SurfaceTextureHelper.java:70)
[        ] E/org.webrtc.Logging(10236): 	at org.webrtc.ThreadUtils$3.run(ThreadUtils.java:173)
[        ] E/org.webrtc.Logging(10236): 	at android.os.Handler.handleCallback(Handler.java:938)
[        ] E/org.webrtc.Logging(10236): 	at android.os.Handler.dispatchMessage(Handler.java:99)
[        ] E/org.webrtc.Logging(10236): 	at android.os.Looper.loop(Looper.java:236)
[        ] E/org.webrtc.Logging(10236): 	at android.os.HandlerThread.run(HandlerThread.java:67)
[   +7 ms] W/System.err(10236): java.lang.NullPointerException: Attempt to invoke virtual method 'android.graphics.SurfaceTexture org.webrtc.SurfaceTextureHelper.getSurfaceTexture()' on a null object reference
[        ] W/System.err(10236): 	at org.webrtc.AndroidVideoDecoder.initDecode(AndroidVideoDecoder.java:154)
[   +2 ms] E/rtc     (10236): #
[        ] E/rtc     (10236): # Fatal error in: gen/sdk/android/generated_metrics_jni/../../../../../../sdk/android/src/jni/jni_generator_helper.h, line 94
[        ] E/rtc     (10236): # last system error: 0
[        ] E/rtc     (10236): # Check failed: !env->ExceptionCheck()
[        ] E/rtc     (10236): # 
[   +7 ms] F/libc    (10236): Fatal signal 6 (SIGABRT), code -1 (SI_QUEUE) in tid 20278 (DecodingQueue -), pid 10236 (le.appname)
iOS log
Call-ID: l37fpb0488o53z6w5e7h

CSeq: 2 BYE

Supported: outbound

Content-Length: 0
flutter: [2021-12-22 17:12:44.868] Level.debug rtc_session.dart:2931 ::: session ended
flutter: [2021-12-22 17:12:44.869] Level.debug rtc_session.dart:1474 ::: close()
flutter: [2021-12-22 17:12:44.872] Level.debug rtc_session.dart:2934 ::: emit "ended"
* thread #40, queue = 'com.apple.coremedia.compressionsession.clientcallback', stop reason = EXC_BAD_ACCESS (code=1, address=0x0)
    frame #0: 0x0000000101576444 WebRTC`___lldb_unnamed_symbol3987$$WebRTC + 260
WebRTC`___lldb_unnamed_symbol3987$$WebRTC:
->  0x101576444 <+260>: ldr    x8, [x0]
    0x101576448 <+264>: ldr    x8, [x8, #0x10]
    0x10157644c <+268>: add    x1, sp, #0xf98            ; =0xf98 
    0x101576450 <+272>: add    x2, sp, #0x7d0            ; =0x7d0 
Target 0: (Runner) stopped.
Lost connection to device.

To Reproduce Start a call, wait 5-10 seconds, end the call. Sometimes the error occurs on the first try, sometimes it takes 10-20 attempts.

Expected behavior The app continues working

Platform information:

Flutter version:

Details
[✓] Flutter (Channel stable, 2.5.3, on macOS 12.0.1 21A559 darwin-x64, locale en-GB)
    • Flutter version 2.5.3 at /Users/user/Desktop/development/flutter
    • Upstream repository https://github.com/flutter/flutter.git
    • Framework revision 18116933e7 (7 weeks ago), 2021-10-15 10:46:35 -0700
    • Engine revision d3ea636dc5
    • Dart version 2.14.4

[✓] Android toolchain - develop for Android devices (Android SDK version 31.0.0)
    • Android SDK at /Users/user/Library/Android/sdk
    • Platform android-31, build-tools 31.0.0
    • Java binary at: /Applications/Android Studio.app/Contents/jre/Contents/Home/bin/java
    • Java version OpenJDK Runtime Environment (build 11.0.10+0-b96-7281165)
    • All Android licenses accepted.

[✓] Xcode - develop for iOS and macOS
    • Xcode at /Applications/Xcode.app/Contents/Developer
    • Xcode 13.0, Build version 13A233
    • CocoaPods version 1.11.2

Plugin version: Encountered this issue on versions 0.6.8, 0.6.9, 0.6.10 + hotfix.1, and 0.7.1

OS: Android and iOS

OS version: Android 11(MIUI 12.5.8), iOS 15.1

solid-yuriiuvarov avatar Dec 03 '21 16:12 solid-yuriiuvarov

Is this behaviour reproduced with flutter-webrtc-demo?

ycherniavskyi avatar Dec 03 '21 17:12 ycherniavskyi

We are using dart-sip-ua and callkeep in our application. I can reproduce this with the dart-sip-ua example.

solid-yuriiuvarov avatar Dec 06 '21 12:12 solid-yuriiuvarov

Just got the same issue but during call answering:

* thread #48, queue = 'com.apple.coremedia.compressionsession.clientcallback', stop reason = EXC_BAD_ACCESS (code=1, address=0x0)
    frame #0: 0x0000000102a6a444 WebRTC`___lldb_unnamed_symbol3987$$WebRTC + 260
WebRTC`___lldb_unnamed_symbol3987$$WebRTC:
->  0x102a6a444 <+260>: ldr    x8, [x0]
    0x102a6a448 <+264>: ldr    x8, [x8, #0x10]
    0x102a6a44c <+268>: add    x1, sp, #0xf98            ; =0xf98 
    0x102a6a450 <+272>: add    x2, sp, #0x7d0            ; =0x7d0 

Technically, as I understand, some media callback is not set in my case and is already removed in your case.

ycherniavskyi avatar Dec 06 '21 15:12 ycherniavskyi

I also conducted a stress test here. The current preliminary test results of sip_ua0.4.0 (webrct0.6.7-0.8.0) will cause a crash or connect to 1005, causing the program to crash or fail to connect to the SIP server. I am doing the same connection compatibility and stability test for other sip_ua and webrct versions, and I will update the report a little bit.

zi6xuan avatar Dec 09 '21 08:12 zi6xuan

@zi6xuan what do mean by "connect to 1005"?

ycherniavskyi avatar Dec 09 '21 09:12 ycherniavskyi

Occasionally there will be a registration failure error code 1005, I don’t know what caused it

zi6xuan avatar Dec 09 '21 14:12 zi6xuan

The results of the compatibility test came out, and finally found sip_ua0.3.7+webrct0.6.7, and the interval between two logout and registration was more than seven seconds, and a maximum of 30 stress tests were performed. All successfully connected and the call was successful. Compatibility test

zi6xuan avatar Dec 09 '21 14:12 zi6xuan

@ycherniavskyi

I think this is the same issue as :

https://github.com/flutter-webrtc/flutter-webrtc/issues/500 https://github.com/flutter-webrtc/flutter-webrtc/issues/499 They all printed the following error: java.lang.RuntimeException: Failed to create EGL context: 0x3003

We encountered this crash in our project either if create/dispose the RTCVideoView more than 191 times on Flutter side.

It seems the releaseEglSurface() in EglRender doesn't release the egl things totally, and something has been left behind.

My platform:

MIUI 12.5.18, android 11

Oppo ColorOS 11.1, android 11

neoyxm avatar Dec 10 '21 06:12 neoyxm

Any advice on how to get around this issue? I'm experiencing it as well. (java.lang.RuntimeException: Failed to create EGL context: 0x3003)

thammaknot avatar Feb 21 '22 17:02 thammaknot

Still would love to get some advice on this.

I tested the flutter-webrtc-demo and it has this issue as well. If I open the demo app on 2 phones and join P2P call 28 times (precisely), it will crash both phones (POCO F3 & Pixel 3a).

The stack is as follows:

03-13 17:29:02.993 11800 15360 I org.webrtc.Logging: EglBase14Impl: Using OpenGL ES version 2
03-13 17:29:02.993 11800 15360 E org.webrtc.Logging: SurfaceTextureHelper: decoder-texture-thread create failure
03-13 17:29:02.993 11800 15360 E org.webrtc.Logging: SurfaceTextureHelper: java.lang.RuntimeException: Failed to create EGL context: 0x3003
03-13 17:29:02.993 11800 15360 E org.webrtc.Logging: SurfaceTextureHelper: java.lang.RuntimeException: Failed to create EGL context: 0x3003
03-13 17:29:02.993 11800 15360 E org.webrtc.Logging: 	at org.webrtc.EglBase14Impl.createEglContext(EglBase14Impl.java:282)
03-13 17:29:02.993 11800 15360 E org.webrtc.Logging: 	at org.webrtc.EglBase14Impl.<init>(EglBase14Impl.java:78)
03-13 17:29:02.993 11800 15360 E org.webrtc.Logging: 	at org.webrtc.EglBase$-CC.createEgl14(EglBase.java:215)
03-13 17:29:02.993 11800 15360 E org.webrtc.Logging: 	at org.webrtc.EglBase$-CC.create(EglBase.java:158)
03-13 17:29:02.993 11800 15360 E org.webrtc.Logging: 	at org.webrtc.SurfaceTextureHelper.<init>(SurfaceTextureHelper.java:187)
03-13 17:29:02.993 11800 15360 E org.webrtc.Logging: 	at org.webrtc.SurfaceTextureHelper.<init>(SurfaceTextureHelper.java:33)
03-13 17:29:02.993 11800 15360 E org.webrtc.Logging: 	at org.webrtc.SurfaceTextureHelper$1.call(SurfaceTextureHelper.java:75)
03-13 17:29:02.993 11800 15360 E org.webrtc.Logging: 	at org.webrtc.SurfaceTextureHelper$1.call(SurfaceTextureHelper.java:70)
03-13 17:29:02.993 11800 15360 E org.webrtc.Logging: 	at org.webrtc.ThreadUtils$3.run(ThreadUtils.java:173)
03-13 17:29:02.993 11800 15360 E org.webrtc.Logging: 	at android.os.Handler.handleCallback(Handler.java:938)
03-13 17:29:02.993 11800 15360 E org.webrtc.Logging: 	at android.os.Handler.dispatchMessage(Handler.java:99)
03-13 17:29:02.993 11800 15360 E org.webrtc.Logging: 	at android.os.Looper.loop(Looper.java:236)
03-13 17:29:02.993 11800 15360 E org.webrtc.Logging: 	at android.os.HandlerThread.run(HandlerThread.java:67)
03-13 17:29:02.994 11800 15339 W System.err: java.lang.NullPointerException: Attempt to invoke virtual method 'android.graphics.SurfaceTexture org.webrtc.SurfaceTextureHelper.getSurfaceTexture()' on a null object reference
03-13 17:29:02.994 11800 15339 W System.err: 	at org.webrtc.AndroidVideoDecoder.initDecode(AndroidVideoDecoder.java:154)
03-13 17:29:02.994 11800 15339 E rtc     : #
03-13 17:29:02.994 11800 15339 E rtc     : # Fatal error in: gen/sdk/android/generated_metrics_jni/../../../../../../sdk/android/src/jni/jni_generator_helper.h, line 94
03-13 17:29:02.994 11800 15339 E rtc     : # last system error: 0
03-13 17:29:02.994 11800 15339 E rtc     : # Check failed: !env->ExceptionCheck()
03-13 17:29:02.994 11800 15339 E rtc     : # 
--------- beginning of crash
03-13 17:29:02.994 11800 15339 F libc    : Fatal signal 6 (SIGABRT), code -1 (SI_QUEUE) in tid 15339 (DecodingQueue -), pid 11800 (utterwebrtcdemo)

I tried it on the latest flutter_webrtc (0.8.3) and the problem still exists.

Is there any way to fix this?

thammaknot avatar Mar 13 '22 10:03 thammaknot

i have the same problem

HuskarHuang avatar Mar 18 '22 05:03 HuskarHuang

I believe I have solved the problem.

I looked at the fix for react-native-webrtc (https://github.com/react-native-webrtc/react-native-webrtc/commit/667712c1b7e5356c3fbf1312802fbdc28de155f3) and adapted it to flutter-webrtc.

Basically, you need to properly clean up the SurfaceTextureHelper object when disposing the video renderer/capturer object.

What I did was, I modified GetUserMediaImpl.java around here: https://github.com/flutter-webrtc/flutter-webrtc/blob/master/android/src/main/java/com/cloudwebrtc/webrtc/GetUserMediaImpl.java#L714

to keep track of the SurfaceTextureHelper object created.

        mSurfaceTextureHelpers.put(trackId, surfaceTextureHelper);

(mSurfaceTextureHelpers is a map I created)

Then, when the video capturer is being cleaned up here:

https://github.com/flutter-webrtc/flutter-webrtc/blob/master/android/src/main/java/com/cloudwebrtc/webrtc/GetUserMediaImpl.java#L730

I simply did

                SurfaceTextureHelper helper = mSurfaceTextureHelpers.get(id);
                helper.stopListening();
                helper.dispose();
                mSurfaceTextureHelpers.remove(id);

For my use case, this got rid of the crashes. I tried by repeatedly creating and releasing video renderers. It used to crash at about 30 video renderers but now it can go up to 100 (I didn't try further).

Note that I still think it cannot handle simultaneous >30 video renderers....but that's much more acceptable now.

thammaknot avatar Mar 20 '22 03:03 thammaknot

I believe I have solved the problem.

I looked at the fix for react-native-webrtc (react-native-webrtc/react-native-webrtc@667712c) and adapted it to flutter-webrtc.

Basically, you need to properly clean up the SurfaceTextureHelper object when disposing the video renderer/capturer object.

What I did was, I modified GetUserMediaImpl.java around here: https://github.com/flutter-webrtc/flutter-webrtc/blob/master/android/src/main/java/com/cloudwebrtc/webrtc/GetUserMediaImpl.java#L714

to keep track of the SurfaceTextureHelper object created.

        mSurfaceTextureHelpers.put(trackId, surfaceTextureHelper);

(mSurfaceTextureHelpers is a map I created)

Then, when the video capturer is being cleaned up here:

https://github.com/flutter-webrtc/flutter-webrtc/blob/master/android/src/main/java/com/cloudwebrtc/webrtc/GetUserMediaImpl.java#L730

I simply did

                SurfaceTextureHelper helper = mSurfaceTextureHelpers.get(id);
                helper.stopListening();
                helper.dispose();
                mSurfaceTextureHelpers.remove(id);

For my use case, this got rid of the crashes. I tried by repeatedly creating and releasing video renderers. It used to crash at about 30 video renderers but now it can go up to 100 (I didn't try further).

Note that I still think it cannot handle simultaneous >30 video renderers....but that's much more acceptable now.

Thank you very much

HuskarHuang avatar Mar 20 '22 07:03 HuskarHuang

can we make a PR with the fix

MohamedRisaldarTA avatar Mar 22 '22 06:03 MohamedRisaldarTA

@thammaknot, so what about PR? Could you create it? If not, then I can create it with provided in your comment modification.

@HuskarHuang do I understand your gratitude correctly - the provided fix has also solved the issue for you?

ycherniavskyi avatar Mar 24 '22 07:03 ycherniavskyi

yes,this fix my problem,thanks!

HuskarHuang avatar Mar 25 '22 03:03 HuskarHuang

Let me find time this weekend to look into this.

I didn't plan on doing it earlier because I didn't completely feel that my solution was 100% optimal (it felt slightly hackish...perhaps). If anyone who's more familiar with the codebase knows a better solution, feel free to take it over.

thammaknot avatar Mar 25 '22 07:03 thammaknot

@cnwangxiao I think this is a valid fix, can you submit a PR for the fix you made?

cloudwebrtc avatar Aug 24 '22 16:08 cloudwebrtc