Crash - SIGSEGV (This issue has 2,546 crash events affecting 989 users)

[buddy-dev-1337]

Describe the bug
This happens intermittently, just try to place a call to someone and we see this.

One interesting thing got from Crashlytics is that for all these crashes the memory in RAM is around 100-200MB at the time of the crash, which is weird because these are mid-high end devices with 4-6GB RAM

Gemini Gist:
A SIGSEGV (Segmentation Violation) in libjingle_peerconnection_so.so indicates a memory access violation within the WebRTC library. This usually means your code is trying to read or write to a memory address it shouldn't access – possibly because the memory is unallocated, already freed, or doesn't have the correct permissions. This often happens due to:

SDK version

• (io.getstream:stream-video-android-ui-compose:1.5.0)

To Reproduce
Steps to reproduce the behavior:

1. Try to call someone with ringing true
2. Decline the call from the other side
3. Observe the crash

Expected behavior
Should not crash the app.

Device:

• Vendor and model: Vivo, Oppo, Xiaomi
• Android version: Android 14, 13, 11, 10

Screenshots
If applicable, add screenshots to help explain your problem.

Logs

stacktrace.txt

[buddy-dev-1337]

Along the same lines as above we are also seeing crashes with

1. SIGILL - This issue has 1,274 crash events affecting 722 users
2. SIGABRT - This issue has 682 crash events affecting 291 users

One thing that stands out with all these issues is that memory in RAM is around 100-200MB, sometimes even less than 50MB at the time of the crash

[aleksandar-apostolov]

Hi there,
Thanks for the report.

I suggest you update to 1.6+ where a OOM and some race conditions were adressed.

Regards,
Alex

[buddy-dev-1337]

@aleksandar-apostolov we released with 1.6.1 but the issue still persists.

Here is the flow of the app
1 - there is CallConnectActivity which initiates a call by taking in userID as the intent
2 - this userID is fed into the call object using call.create(with ring true) and timeout of 10s
3 - since the other side does not respond we get a CallRejectedEvent on which we perform call.end()
4 - delay(500)
5 - start from step 1 with a different userID from the queue
6 - Crash happens

Initially we were not doing call.end() when the other side did not respond and would proceed calling the next person in the queue, but this also did crash.

Question - what is the right way to keeping calling members from a queue?
Expectation - try 1st person from the queue, if connects, well & good. If not what are the correct steps to close the previous call and start new call to the next person in the queue, this crash only happens in this continuous flow.

Your help is highly appreciated, our crash-free rate stand at 90% currently and we want to improve it.

[aleksandar-apostolov]

Hi @buddy-dev-1337

You also need to call call.leave() to cleanup internal state.
Without having knowledge on your integration I would suggest if not already to create a call object before each process via client.call(type, id).

Regards,
Alex

[buddy-dev-1337]

@aleksandar-apostolov call.end() internally calls call.leave() so I can still use call.end() right?

/** ends the call for yourself as well as other users */
suspend fun end(): Result<Unit> {
    // end the call for everyone
    val result = clientImpl.endCall(type, id)
    // cleanup
    leave()
    return result
}

[aleksandar-apostolov]

Yes, but when you do call.end() this makes the call marked as ended on the backend. If you want to continue using the call you can call call.leave() or call.reject() on the side that needs to leave. Technically you can rejoin an ended call depending on permissions, but this depends on the usecase.

Would you like to share how you integrate this? I need to know how are you "calling the next member".

Regards,
Alex

[buddy-dev-1337]

Hello @aleksandar-apostolov sharing the code for the Activity which creates the call and if someone rejects or does not pick we move to picking next random member from the list.

I did upgrade the SDK to 1.6.1 but the issue persists.

Core functions of the Activity

• initiateCall (responsible for initiating a call given an ID, on CallRejectedEvent we move to the below step)
• startRandomFlow (picks random member from the list and initiates call with them)

Gist - https://gist.github.com/buddy-dev-1337/930041dfec734ba44bb69d3a7838370f