fix: Application Not Responding at shorebird_init on some devices #1981
Assignees
Labels
bug
Something isn't working
Comments
bryanoltman
changed the title
|
This is certainly not what we want to happen. Are you able to share code that reproduces this issue, or to provide more information? There isn't a lot to go off of in this report. |
|
Definitely unexpected. We should be able to symbolicate the rest of the stack with our Android flutter build artifacts, similar to what we've wired up for iOS. |
|
Looks like the app_id is cc6ea63a-aad2-4b11-98fc-bb03a0f5a794. |
|
Looks like all recent versions were built with flutter aee5222c0d52012f089564a8395826d56e7c2fe8 |
|
https://docs.shorebird.dev/guides/crash-reporting.
Symbols are at https://download.shorebird.dev/flutter_infra_release/flutter/e4434d7a212b29a8ee8ffaf8e2c453c753904933/android-arm64-release/symbols.zip And ndk-stack or atos should be able to symbolicate. |
|
any updates? I'm thinking to remove |
|
Apologies for failing to follow up here earlier. @bryanoltman are you able to symbolicate the crash stack this afternoon? If not, let me know and I'm happy to help. @canewsin since we don't yet know what's wrong (until we look at the stack in more detail), yes removing Shorebird is the only option at this time. We'll let you know as soon as we learn more (hopefully later today). |
|
Steps (as I understand them):
I'm sure ndk-stack or whatever will do that for you automatically, but it's probably easier to symbolicate the 5 respective lines by hand. I supect we'll find that it's hanging down in the rust http stack. |
|
If the build_id does not match, then we haven't found the right symbols. There must be better docs for it than this, but this is what I found: https://github.com/mattst88/build-id build_id is essentially the same as the uuid concept used in .dsym files on Mac. Just a different name for the elf vs. macho worlds. |
|
I was wrong. Turns out the NDK is in: And the bin is not |
|
Looks like the modern command is: |
|
Looks like I'm also wrong about which numbers are which 🤣 So for:
8163328 is 0x7C9000 in hex, which is a nice round number and likely a library load offset? Except the PCs reported are really small (smaller than that offset in some cases) which would suggest they're not library load offsets. Unless the PCs are already subtracted relative to their load offset, but that would be surprising. |
|
The information typically needed to understand a stacktrace are just two things:
In this case we're missing the load offset pairs (typically at the bottom of a stack trace), but maybe it's embedded into those lines in ways I don't understand. The symbol lookup process is then just taking the pc - load offset to get a file offset, and then looking up the symbol corresponding to that file offset in the associated file for that build_id/name |
|
@canewsin Curious, are you able to provide us a more complete stack trace? Typically they include a line: |
|
@eseidel Attaching latest stack traces from playstore |
|
Working down the stack: |
|
This is super helpful @canewsin! Looks like we might have a deadlock in our updater code. Looking now. |
|
We understand the bug. The sequence is:
We could/should probably fix both bugs (although fixing either should fix this). @bryanoltman is working on testing and fixing now. We'll likely release a fix on Weds with the expected Flutter update. |
|
My guess (although I don't know) of why you're seeing this and others are not is that you presumably are using either multiple Flutter engines, or using Firebase Cloud Messaging (or another service that wakes up the Flutter engine in the background), thus shorebird_init has already been called before the real "launch" of the app, and it just so happens that sometimes these phones are on slow networks and also happen to be making a background call to check_for_update while the launch is happening, and this shorebird_init call hangs. If you're using package:shorebird_code_push to trigger an update check manually, that may be contributing to the frequency of the ANRs, but the real bug is ours and we'll have a fix soon. We don't yet have the capacity to back-port fixes to older flutter revisions, with a new Flutter release expected this week, we expect this will only be fixed in 3.22.0 and later once we release it. |
|
Just wanted to thank you again for reporting @canewsin. I suspect we've had this bug for over a year now and you're the first to report it! Regardless, Bryan has a local fix now which should go out later this week. |
|
@canewsin Just to confirm/debunk a theory: are you using |
|
@eseidel @bryanoltman yup
|
|
Looks like Flutter 3.22 was released this morning, so I expect our Flutter 3.22 (with this fix) will be out later today. |
|
Guys we are still facing this issue with lot of ANR, Please suggest us the solution. shorebird_init |
|
@uc-asa can you share a more complete stack trace? Edit: along with your app id and release version |
|
I suspect the app_id is still cc6ea63a-aad2-4b11-98fc-bb03a0f5a794, but the release version would help a lot to know. |
|
My app id is different and it's here is stack trace: |
Ah, then this is unfortunately expected – the fix is only present in the 3.22.0 release. |
|
As Bryan notes, we don't currently have a system for back-porting any fixes (we could build one, but currently we have a very small team), so when we fix something in Shorebird at the engine level (rather than the |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
App ID:
cc6ea63a-aad2-4b11-98fc-bb03a0f5a794Stacktrace
Steps To Reproduce
ANR triggered on some devices
Additional Context
I see that some devices had an immediate ANR triggered 1 second apart in same session.
Few Device List
OS version: android13 Model:CPH2213
OS version: android13 Model:Redmi Note 11 Pro+ 5G
OS version: android13 Model:V2058
OS version: android13 Model:Vivo Y22
OS version: android11 Model:Redmi Note 10
OS version: android12 Model:A Series
The text was updated successfully, but these errors were encountered: