Skip to content
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

Java_com_twilio_voice_Call_nativeMute produces "null pointer dereference" crash #639

Open
jamesbluecrow opened this issue Dec 3, 2024 · 7 comments

Comments

@jamesbluecrow
Copy link

jamesbluecrow commented Dec 3, 2024

Description

We see a crash sometimes when calling call.mute(false).

null pointer dereference: SIGSEGV  0x0000000000000088
#00 pc 0x3a19bc libtwilio_voice_android_so.so (BuildId: 62e0d7afc022295681860f9c7a2da6256bf21058)
#01 pc 0x3a9e64 libtwilio_voice_android_so.so (Java_com_twilio_voice_Call_nativeMute) (BuildId: 62e0d7afc022295681860f9c7a2da6256bf21058)

Steps to Reproduce

No clear repro steps, it doesn't happen often but we definitely see around 90-100 instances of this crash every week.

Expected Behavior

No crash happening.

Actual Behavior

Sometimes it the app crashes and because it's in the native code we can't really catch the exception.

Reproduces How Often

Marginal. 1% or less.

Twilio Call SID(s)

CAac2be52efa19f212ba1f0dd8654771d1

Logs

null pointer dereference: SIGSEGV  0x0000000000000088
#00 pc 0x3a19bc libtwilio_voice_android_so.so (BuildId: 62e0d7afc022295681860f9c7a2da6256bf21058)
#01 pc 0x3a9e64 libtwilio_voice_android_so.so (Java_com_twilio_voice_Call_nativeMute) (BuildId: 62e0d7afc022295681860f9c7a2da6256bf21058)

Voice Android SDK

com.twilio:voice-android:6.7.0
com.twilio:audioswitch:1.2.0

OS Version

It happens in multiple Android versions: Android 11, 12, 13, 14, 15

Device Model

It happens in multiple device models. Samsung, Google Pixel, etc.

@afalls-twilio
Copy link
Contributor

@jamesbluecrow Thanks for the report, any additional information you can provide so that we can possibly repo the issue?

@jamesbluecrow
Copy link
Author

jamesbluecrow commented Dec 10, 2024

Hey @afalls-twilio.

The repro steps would be:

val call = callInvite.accept()
call.mute(false)

But we haven't been able to reproduce the crash ourselves.

I know the information I'm providing is not very helpful, but the traces coming out of the NDK doesn't really tell us much. I would assume that something in the call is not ready yet and is null internally.

@afalls-twilio
Copy link
Contributor

afalls-twilio commented Dec 11, 2024

@jamesbluecrow I haven't been able to reproduce with the quickstart but looking at the code, I suspect that the call.release() has been called before mute was being called. There is a private member of the call object called nativeCallDelegate that I suspect is 0 (which is only the case when call.release has already called).

Is it possible that call.mute() is being called while the call is disconnecting?

or is it being called from a different thread than the rest of Voice sdk method are calls coming from?

@jamesbluecrow
Copy link
Author

No, we are calling it from the same thread and immediately after accepting the call.

We were trying to do this because some users complained about 1 way audio and they mentioned that the steps mute/unmute was fixing it for them so we assumed there could be some kind of cache there that was causing the issue so this was supposed to be a workaround.

Unless there is the possibility that the call gets disconnected before callInvite.accept() returns it I don't see how that could happen.

@afalls-twilio
Copy link
Contributor

afalls-twilio commented Dec 12, 2024

@jamesbluecrow hmm... this and the other issue you reported, unless we can find a way to reproduce it with the QuickStart or some other demo application where we can share code, not sure what we can do from here as we have not been able to reproduce it (and thus find a fix for it, or even diagnose it).

@jamesbluecrow
Copy link
Author

@afalls-twilio to me, it does feel like there is some kind of race conditions in the SDK.

This issue is less important because we probably should not be calling mute(false) right after the invite is accepted anyway.

The other issue though is definitely critical.

@afalls-twilio
Copy link
Contributor

afalls-twilio commented Dec 13, 2024

@jamesbluecrow I would be surprised if that were the case as on one has ever reported this before. Either way, check out my response at the other GH issue, especially the part about sdk calls made from threads that are not looper threads. If its the case, that would explain both of these issues.

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

2 participants