-
Notifications
You must be signed in to change notification settings - Fork 140
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
Native SDK crashes on Java_com_twilio_voice_Voice_nativeHandleMessage for incoming calls #641
Comments
@jamesbluecrow Thanks for the information. It looks like a null pointer of some kind but we have not been able to reproduce it on our end. Have you been able to reproduce it at all with the quickstart? |
No unfortunately I haven't been able to reproduce it in the quickstart, but neither I have been able to reproduce it on our own app. In perspective we see weekly around +3k crashes affecting +2k users. The ratio is of just 1.5 crash per user and with the volume of calls we have is small so really hard to reproduce. But the numbers are too high to ignore. Sorry I am not being able to help giving you clear repro steps. |
Our code to handle the notifications though is almost a copy paste of what the quickstart project is:
|
@jamesbluecrow hmm... what happens when you run your app, background it and kill it, then call it... or maybe wait 5 min before calling it. I'm wondering if there is something strange regarding lifetimes... the null pointer crash in native is very unusual. |
I've tried that but no luck, I don't see any problem and calls come normally. Looking at our firebase again I see there is a different variant that has different trace, but this other variant crash has happened only 6 times in the last 7 days. I'll post it here in case they are related and it helps:
|
@jamesbluecrow that call stack looks truly odd... looking at the source and there has been no luck in reproducing the issue at all, any usage patterns? we could not reproduce it with the QuickStart on our end either Actually, Can you check something for me? what is in |
Doing some quick maths we see this crash happening for around 0.5 of the calls handled by our app which makes it extremely difficult to reproduce it. To me it does look like there is likely some kind of race condition in the SDK (I'm surprised that other apps that have integrated the SDK are not experiencing this to the same level we see). There is no other calls to the SDK aside of |
@afalls-twilio does I'm looking more into our logs and I see something that suggests that this crash not only happens for incoming alls but also for outgoing calls. |
@jamesbluecrow The two issues you have reported, no one has reported before. Its very unlikely that a race condition is occurring if all the SDK calls are being made from the same thread. Is it possible that the thread your application is making the SDK calls from, is not a thread with a Looper? If the thread does not have a looper, then all the callbacks from the SDK get posted to the UI thread (which has a looper), which can cause multiple SDK calls coming from different threads if subsequent sdk calls are made from those callbacks. Also, |
@afalls-twilio as you can see in the code I posted we don't really have threads playing a part here #641 (comment) . This code is copied from our project (I only removed the parts that are not relevant). I don't have data to prove my suspicion, but looking at one specific crash for one of our users it does suggest that we got registered the crash in firebase right after the user tried an outgoing call. Anyway all the other crashes breadcrumbs I see seem to be always when incoming calls so maybe I'm just misreading the logs. |
@afalls-twilio were you able to find anything about this? I saw your last comment (now removed) about potentially being an issue if there is an incoming call happening at the same time than an outgoing call? |
@jamesbluecrow unfortunately, nope. As i said before As for an incoming call at the same time as an out going call, I have not been able to repro a crash. have you been able to repo that with the quickstart? is your application accepting the call directly from the firebase service? |
@afalls-twilio I'm not sure what you refer with For a user to accept the call we first display a notification so no, accepting the call is done somewhere else. Ps. No we haven't reproduced the issue with the quickstart, but neither on our own app which just shows its tricky to reproduce. |
@jamesbluecrow I was trying to brainstorm of situations where there could be a violation of the threading contract... which is..
yeah, this issue is tough since neither party has been able to reproduce it. One other thing is maybe release a version that logs the data being sent to How much logging are you able to capture before the crash? |
I'll see if we can get some logs with the data is sent to |
@afalls-twilio Just one crash happened and the data sent to
|
@jamesbluecrow do you have device logs? |
@jamesbluecrow Thanks, I'll circle back internally. I'm also going to try to feed that message into |
@jamesbluecrow So I made a demo taking the data you posted earlier, and re-sending it into Also, although you posted your code earlier and it didn't seem like it was a possibility, I thought I would ask anyway. In your app, are you checking/logging if Anyway, the demo is here let me know how it goes. |
Hey @afalls-twilio , I'll test this out. To your question, no there is no cache involved and I could see in the logs that |
@afalls-twilio I see an error when I try to download the demo, could it be that the file is missing some permissions? Ps. I did try just harcoding the payload in our own app and I couldn't reproduce the issue either. |
Description
We see many crashes in our app when receiving incoming calls.
The trace is not very useful so we don't really know how to approach this. Everything is done in the Main thread as the push notification arrives.
Steps to Reproduce
No clear repro steps, we haven't been able to reproduce it but we see +2k crashes weekly from this. It looks like it mostly happens for incoming calls
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
7% of our users are affected by this.
Twilio Call SID(s)
CAa37e338e2a412480cd171bdd92b1fc9a
Logs
Voice Android SDK
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.
The text was updated successfully, but these errors were encountered: