[AVCaptureSession stopRunning] crash

[badarovska]

Getting crash logs in my production app:

-[AVCaptureSession stopRunning] stopRunning may not be called between calls to beginConfiguration and commitConfiguration

Similar issue that was fixed: https://github.com/opentok/opentok-ios-sdk-samples/issues/279

• iOS SDK version: 2.25.2
• OS and version: multiple versions of iOS15 and iOS16

[v-kpheng]

@badarovska, was this issue fixed by iOS SDK 2.25.0? If so, are you seeing regressions in 2.25.2? Can you still reproduce in 2.26.0?

Lastly, do you have steps to reproduce?

[badarovska]

A similar issue was fixed, but not his one. [AVCaptureSession startRunning] was fixed in 2.25.0. But since 2.25.0 I'm getting a crash for [AVCaptureSession stopRunning]. It was also reported here.

I can confirm that is happening on 2.25.2. Not sure about 2.26.0, since I have not updated to that version yet. I have not been able to reproduce it locally, but I'm getting crash reports on my production app. As far as I can see from the reports it's happening when the call is ended.

[PriyankaThread]

We are facing the same crash issue with version 2.24.3, So please let us know which version supports it and any possible way to fix it with the same version. We need to find a solution for the issue This version fixes an issue where it sometimes took longer than expected to disconnect from a session. version 2.24.3 only supports and works with our existing source code, So Can you help us and provide which version have fixed this issue apart from 2.26.1 & 2.25.4 because both version not supported our source code.

[vadimvitvickiy]

Had this issue on the 2.26.1. We had to stop calling OTPublisher = nil when leaving the call, and it seems to help. But it's not an ideal solution, and now we have the crash while creating OTSubscriber sometimes.

[v-kpheng]

Apologies for the belated reply. We're tracking this internally: https://jira.vonage.com/browse/VIDCS-1608. It's been added to an upcoming sprint.

[v-kpheng]

No one on the team has been able to reproduce this issue. That said, we have an approach that may help.

Is anyone willing to try out a test build?

[vadimvitvickiy]

@v-kpheng currently we're experiencing this issue in our app. The crash seems to be related to recreating existing OTPublisher, or simply calling OTPublisher = nil. It might be some other AVCaptureSession configuration code is executing in parallel of deinint for OTPublisher and make it crash.

At first, we had this crash while leaving from the call and niling OTPublisher pointer. Now we have it sometimes when we have to recreate the session and the OTPublisher while other session is existing. We destroy the session properly before doing so, and the crash seems to be random, not always reproduced.

We could try to test a build with possible fix.

[jvalli]

@vadimvitvickiy What bundle format are you working with? old fat framework or xcframework? So we can share with you a new build. Also can you share with us some sample of code? Are you performing the following steps?: 1.- create new session 2.- connect to session 3.- create new publisher 4.- start to publish 5.- stop to publish 6.- disconnect from session 7.- cleanup publisher

[vadimvitvickiy]

@jvalli

What bundle format are you working with? old fat framework or xcframework? So we can share with you a new build.

We're using SPM right now, so it either some test SPM build or binary that we can add through it.

Also, I've tracked when the crash first appeared and it exactly in the first version where we've added the first vonage version with SPM support.

Also can you share with us some sample of code? Are you performing the following steps?:

Yes, but with these steps, you also shouldn't wait until callbacks are called for unpublish or session destroy. Right after calling unpublish and disconnect, call publisher = nil. With those steps, we had no crashes when user would leave the call if we do not nil the publisher, but the crash reproduces now when user switches between sessions. Meaning, we're recreating the publisher when something executing in the framework in parallel, it's my guess.

[jvalli]

@vadimvitvickiy Why are you destroying the publisher if you are waiting for a callback? You shouldn't do that, if you send a request to unsubscribe, unpublish or disconnect, the SDK will be trying to use the subscriber, publisher or session objects until the specific callback is received. You can only release memory objects after receive the callback, once the object is not being used any more by the SDK, otherwise you produce an unexpected scenario.

[vadimvitvickiy]

@jvalli Right now, we do not destroy it before all callbacks are called. I mentioned it as a case for crash reproduction. At the moment, crash is reproduced even if we wait for all the callbacks to be called and then rewrite the publisher pointer with a new one when we need to create a new session after another. Keep in mind that it not reproduces every time, it's randomly crashing after multiple tries.

[jvalli]

@vadimvitvickiy Can you share a piece of sample code? There should be something else, we are doing the same on our internal apps and there is no crash. Anyway we have a sanity check fix that you can try on SPM branch bug/VIDCS-1608:

[vadimvitvickiy]

@jvalli

Can you share a piece of sample code?

I could, but I would have to share at least 3 classes in order to show the whole picture.

There should be something else, we are doing the same on our internal apps and there is no crash.

The problem is this crash is hard to reproduce. It could be once per 10–30 tries, could be none at all.

Anyway we have a sanity check fix that you can try on SPM branch bug/VIDCS-1608:

Thank you, we will try it, but it might take some time.

[vadimvitvickiy]

The crash is not reproducing anymore. When we could expect this fix in the new version of the framework?

[ve-sdk-ios]

Facing the original issue and sometimes we see this stacktrace in our app on version 2.26.2. When the fix will be available?

[vadimvitvickiy]

Version 2.27.0 the crash is still reproduced. Though it is fixed in bug/VIDCS-1608 branch.