opentok-ios-sdk-samples
opentok-ios-sdk-samples copied to clipboard
Crash after closing video call
Describe the bug Crash appears after several starting and closing the call in our app. Crash reproduces on iPhone 12 iOS 17.2.1(several devices) and not reproduced on iPhone X iOS 16.7.1.
To Reproduce I reproduce this crash in our fork from this repo: https://github.com/ve-sdk-ios/opentok-ios-sdk-samples. There is additional start screen with button "Start call" and "Close" button at existing ViewController screen. Action at "Start call" opens yours controller in Video-Transformers sample
Steps to reproduce the behavior:
- Push button "Start call"
- Wait until preview appears
- Push button "Close"
- Wait until camera and micro lights disappear (green and orange circle in status bar).
- Repeat steps
After several times it can be like 3-5 or more the crash appears.
Expected behavior Crash should not be exists
Screenshots
Device (please compete the following information):
- sessionId, if applicable: 1_MX40NzUyMTY1MX5-MTcwNDQ0NzM0MjUxNH53cHBYMSs0eDFER0JvQ0c0TzVLU3M3UHl-fn4
- iOS SDK version: 17.2.1
- OS and version: MacOS Sonoma 14.1.2 (23B92)
- OpenTok 2.27.0
Additional context
In our app we have got similar issue but stack trace is different. We have tried to disconnect session before closing the view but it wouldn't help
Hello @ve-sdk-ios, can you provide a detailed stack trace? Just using bt all
in xcode debug console. cc @IGitGotIt
There is full console output with bt all
stacktrace.txt
I could not reproduce it. I tried your code and went through the steps 3 X 5+ times (publish only). Then I did it once with self subscribe. No luck. Maybe I am missing something.
Anyway one suggestion would be to un-publish when the call is closed and do a dismiss on
- (IBAction)closeAction:(id)sender {
[_session unpublish:_publisher error:nil];
}
- (void)publisher:(OTPublisherKit*)publisher
streamDestroyed:(OTStream *)stream {
[self dismissViewControllerAnimated:YES completion:nil];
}
Hopefully that will free up the camera in time for the next sequence of Start. Let me know if that helps.
Also from the logs I see
thread #11
frame #0: 0x00000001d76cef0c libsystem_kernel.dylib`kevent + 8
frame #1: 0x0000000102245edc Video-Transformers`-[OTSubscriber initWithStream:delegate:] + 969564
frame #2: 0x0000000102241f34 Video-Transformers`-[OTSubscriber initWithStream:delegate:] + 953268
frame #3: 0x00000001021cadb4 Video-Transformers`-[OTSubscriber initWithStream:delegate:] + 465460
frame #4: 0x000000010217f174 Video-Transformers`-[OTSubscriber initWithStream:delegate:] + 155124
frame #5: 0x00000001f9f744d4 libsystem_pthread.dylib`_pthread_start + 136
Are there subscribers involved?
I will keep on trying to repo. I tested on iPhone 12 Pro/ 17.1.2 btw.
I tested without subscribers. I have updated the our fork with your recommendation here. Still crashed but something new. In unpublish I have got sometimes I got error (OTSessionErrorDomain error 1011.)
See the new stacktrace
stacktrace2.txt.
UPD: Looks like I close the screen before publishing is started
It's become difficult to reproduce but it still possible. I see this error in console
Capture session runtime error: Error Domain=AVFoundationErrorDomain Code=-11800 "The operation could not be completed" UserInfo={NSLocalizedFailureReason=An unknown error occurred (-16401), NSLocalizedDescription=The operation could not be completed, NSUnderlyingError=0x283fd0cf0 {Error Domain=NSOSStatusErrorDomain Code=-16401 "(null)"}}
After that I successfully started a new publishing and on close action got crash
stacktrace3.txt
In your logs what is
- FigCaptureSourceRemote (as the
Capture session runtime error
follows those logs) - Why are we seeing
[OTSubscriber initWithStream:delegate:]
when there are no subscribers in the test setup
Will it be possible to try a session unpublish and disconnect
on Close
and then dismissing the modal on sessionDidDisconnect
instead of publisher streamDestroyed
. Let's follow the life cycle the whole way.
Lastly will it be possible to just not use the modal controller and just do the publisher on the main view like it was initially in that sample. That will sort of narrow down the cause of the crash (big if...)
- It is logs from yours SDK. I added only start screen and logic to dismiss the call screen.
- As you can see in logs there is not any "session streamCreated" logs. So I have no Idea why we are seeing this in stacktrace.
I refactored fork with your instructions and it still crashes. stacktrace4.txt
It is our use case. User can start the live stream and finish them. And after that start a live stream again. We are expected that all will work without crashes.
I wish I can reproduce it so we don't go back and forth so much. Thanks for your patience. Anyway the EXC_BAD_ACCESS
in trace does not give more information and all those [OTSubscriber initWithStream:delegate:]
are confusing the trace.
It is strange we are seeing this. Just for experimentation can you turn off all transformers code. Just a plain vanilla publish - unpublish - disconnect (start and close in modal) and check if it is reproducible. Thanks
@IGitGotIt @juliobecerragomez Did you fix something on your side? I can't see anymore logs
<<<< FigCaptureSourceRemote >>>> Fig assert: "! storage->connectionDied" at bail (FigCaptureSourceRemote.m:235) - (err=0) <<<< FigCaptureSourceRemote >>>> Fig assert: "err == 0 " at bail (FigCaptureSourceRemote.m:253) - (err=18 446 744 073 709 535 163) <<<< FigCaptureSourceRemote >>>> Fig assert: "err == 0 " at bail (FigCaptureSourceRemote.m:669) - (err=-16453) <<<< FigCaptureSourceRemote >>>> Fig assert: "! storage->connectionDied" at bail
And the crash is not reproducible now.
@IGitGotIt @juliobecerragomez Did you fix something on your side? I can't see anymore logs
<<<< FigCaptureSourceRemote >>>> Fig assert: "! storage->connectionDied" at bail (FigCaptureSourceRemote.m:235) - (err=0) <<<< FigCaptureSourceRemote >>>> Fig assert: "err == 0 " at bail (FigCaptureSourceRemote.m:253) - (err=18 446 744 073 709 535 163) <<<< FigCaptureSourceRemote >>>> Fig assert: "err == 0 " at bail (FigCaptureSourceRemote.m:669) - (err=-16453) <<<< FigCaptureSourceRemote >>>> Fig assert: "! storage->connectionDied" at bail
And the crash is not reproducible now.
That's good. No we did not do anything. Did you restart the phone ?
@IGitGotIt how does restarting phone impact on the crash? As you know we cannot ask users to restart the phone before opening the feature Live Stream.
@IGitGotIt how does restarting phone impact on the crash? As you know we cannot ask users to restart the phone before opening the feature Live Stream.
I was just asking "was the reason you are not seeing any crashes NOW, was because you restarted the phone or not". Nobody recommends what you are saying as a solution, btw.
Is the issue fixed now, since you are not seeing any more crashes. Thanks
@IGitGotIt , we are still experiencing the same crash in our build and cannot release the app.
@IGitGotIt , we are still experiencing the same crash in our build and cannot release the app.
I am confused by conflicting messages about crashes happening and not happening here and I have not been able to repo the crash with the original sample code.
Anyway did you try our previous "experimental" recommendation https://github.com/opentok/opentok-ios-sdk-samples/issues/304#issuecomment-1889903694 . What was the result?
Thanks
@ve-sdk-ios @GlebPBanuba meanwhile we were able to reproduce your issue. Sorry for the late update, but the issue was already solved on 2.27.2 release. Please check release docs
If you still are facing the issue in the latest version please re-open the ticket again.