The iOS Firefox app is crashing when foregrounding the app
Categories
(Data Platform and Tools :: Glean: SDK, defect, P1)
Tracking
(Not tracked)
People
(Reporter: omitchell, Assigned: janerik)
References
Details
Attachments
(4 files)
Screen Shot 2022-09-21 at 10.43.42 AM.png
The app crashes with the error "Task created in a session that has been invalidated" which usually occurs when something attempts to use a URLSession task object that has been invalidated.
This happens a few seconds after the app has been foregrounded.
Here is the Sentry crash report https://sentry.io/organizations/mozilla/issues/3546168631/?environment=Production&project=6176941
This occurs on version 105 of the app. In this version the Glean framework was updated from version 43.0.2 to version 51.0.1.
|
||
Comment 1•2 years ago
|
||
Hi :omitchell!
I can't access that link. Would you kindly give our team permissions to view that link or add the details here? Thanks!
I don't think I have the right access level to grant anyone permissions on Sentry.
I have attached a picture of the stack trace if that helps.
|
||
Comment 4•2 years ago
|
||
I have access to the right Sentry teams to see this already. I'm looking into this now. Thank you for suggesting the URLSession for a good place to start looking.
|
|
||
Comment 5•2 years ago
|
||
|
Assignee | |
Comment 6•2 years ago
|
||
|
|
||
Comment 7•2 years ago
|
||
Changes have made it all the way downstream and have been uplifted into Firefox iOS v106.
Closing this as FIXED
|
|
||
Comment 9•2 years ago
|
||
I took a glance at Focus iOS for this same error, since they are using Glean with the same code, and while it does pop up there, it is definitely happening much less frequently.
I have a 1:1 with Jan-Erik in a few minutes where we will discuss this issue. I'll add a comment with the next steps we will take to address this.
|
Reporter | |
Comment 10•2 years ago
|
||
Thanks. Let me know if there is anything I can do from the client side to help debug this.
|
|
||
Comment 11•2 years ago
|
||
After some lengthy discussion with Jan-Erik today, we came to the conclusion implemented by the attached PR. I would also be grateful to someone on the iOS team taking a little closer look/review of this to ensure we are on the right track.
|
|
||
Comment 12•2 years ago
|
||
In the meantime, I'll be using this PR to do a little local testing in Firefox iOS, but unfortunately we haven't been able to reproduce this error locally so I'm not entirely sure I can verify it fixes the crash seen in Sentry.
|
|
Assignee | |
Updated•2 years ago
|
|
|
Reporter | |
Comment 13•2 years ago
|
||
Since this change is kind of just a best guess it would be good to reduce the turn around time on finding out if it works so we are going to do a hotfix. Let me know when this is ready for the mobile client to consume and I will integrate the change over there.
|
|
||
Comment 14•2 years ago
|
||
The attached (second) PR has merged, I'm going to leave this bug open until we get some signal back that it has impacted the crash stats.
This should just require a Glean release to be able to update for a hotfix. Let me see about getting that release and I'll ping you once it is available or once I know more about when it will be available.
|
|
||
Comment 15•2 years ago
|
||
Okay, this should be available for the hotfix now: https://github.com/mozilla/glean-swift/releases/tag/51.6.0
cc Orla
|
|
Reporter | |
Comment 16•2 years ago
|
||
106.1 went live today, I'll keep an eye on the logs for a couple of days as it rolls out and I'll update this thread thread with the results.
|
|
Reporter | |
Comment 17•2 years ago
|
||
This is still occurring on 106.1. Hard to say if it's at the same rate because adoption is still low but it looks like it's going to ramp up similarly to previous versions.
|
||
Comment 18•2 years ago
|
||
Additional information from a user we received on SUMO:
One more thing that I realized is if I move the application to the background and I wait for some seconds (or open another app) before opening back Firefox, everything is perfect. If the application is moved to backgroud and back to foreground quickly, it is 100% that it crashes. However, sometimes it is still slow and the flashing icons are still present. I hope you can fix this issue.
|
|
Assignee | |
Comment 19•2 years ago
|
||
Thanks! That's good information and it's already something I suspected, but I'm not able to reproduce it.
We will have a meeting today to take a closer look again.
|
|
Assignee | |
Comment 20•2 years ago
|
||
Meeting summary:
Hypothesis why this is happening now: We recently ramped up data collection on iOS, which means we might now have more things to upload. That takes longer, which then leads to those crashes.
We're not able to pin-point this to any particular thing. It might be an underlying bug in how these session work.
2 potential fixes:
- If we need this to be in the background: spawn a background task, ask for addtional processing time, use that to upload
- Handle background notification. Process last upload task. Wrap up within 10-15s (the default timeout for backgrounded apps)
As a short term fix while we implement one of the above: we remove the finishTasksAndInvalidate(). At worst this should only leak memory (until the app quits anyway).
We should monitor data volume/timing after any of these changes.
|
|
Assignee | |
Updated•2 years ago
|
|
|
Assignee | |
Comment 21•2 years ago
|
||
|
|
Assignee | |
Comment 22•2 years ago
|
||
|
|
Assignee | |
Comment 23•2 years ago
|
||
I've been spending all day long trying to identify and/or fix this bug. I haven't found anything.
We decided to go with the above merged PR for now. I'm doing a release right now.
|
|
Assignee | |
Comment 24•2 years ago
|
||
v51.8.0 is out. :travis is gonna get that into firefox-ios once the Swift build is done.
|
|
||
Comment 25•2 years ago
|
||
The Glean v51.8.0 update has landed in Firefox iOS on Friday
|
|
Reporter | |
Comment 26•2 years ago
|
||
Confirming this crash is no longer showing up in the logs for iOS version v106.2.
Description
•