fix: iOS Crashing at 0xffffffffe #1698
Comments
|
Interesting, the second one is 0x0000007ffffffffe? That's not something I would expect. |
|
I split off the second one into a separate issue: #1699 |
|
Developer reports: |
|
I believe this is 6b08519a-93e2-4f55-90c7-ce1c04db32ca. |
|
Hey @eseidel I think I maybe experienced the same crash on iOS. The devices tested on:
Shorebird 0.25.1 • git@github.com:shorebirdtech/shorebird.git StacktraceOS Version: iOS 17.2.1 (21C66) Report Version: 104Exception Type: EXC_BAD_ACCESS (SIGBUS) Application Specific Information: Thread 2 Crashed: Thread 0 Thread 1 name: com.apple.uikit.eventfetch-thread Thread 2 name: io.flutter.1.ui Crashed: Thread 3 name: io.flutter.1.raster Thread 4 name: io.flutter.1.io Thread 5 name: io.worker.1 Thread 6 name: io.worker.2 Thread 7 name: io.worker.3 Thread 8 name: io.worker.4 Thread 9 name: io.worker.5 Thread 10 name: io.worker.6 Thread 11 name: dart:io EventHandler Thread 12 name: io.worker.1 Thread 13 name: io.worker.2 Thread 14 name: io.worker.3 Thread 15 name: io.worker.4 Thread 16 name: com.google.firebase.crashlytics.MachExceptionServer Thread 17 Thread 18 name: SentryCrash Exception Handler (Secondary) Thread 20 name: io.sentry.app-hang-tracker Thread 21 name: com.apple.NSURLConnectionLoader Thread 22 Thread 23 Thread 24 Thread 25 Thread 26 Thread 28 name: DartWorker Thread 29 name: DartWorker Thread 30 name: DartWorker Thread 31 name: DartWorker Thread 32 name: DartWorker Thread 33 name: DartWorker Thread 34 name: DartWorker Thread 35 name: DartWorker Thread 36 name: DartWorker Thread 37 name: DartWorker Thread 38 name: DartWorker Thread 39 name: DartWorker Thread 2 crashed with ARM Thread State (64-bit): EOF |
|
Also it might be connected to this one (#1709), since the crash happens to me as well when I do a navigation attempt. Although the navigation part for me is changing the bottom navigation selected page, and adding a custom Navigator to do child navigation. But all 4 bottom navigation options have the same setup, but only one crashes the entire app on iOS. Android is working as expected. |
|
Thank you very much for the report! We've isolated 2 crashers and have fixes in progress which we expect to release today. I'm still not sure if those will fix this issue though. We've also added a guide on downloading .dSYM files for any given release which if uploaded to Sentry will give you slightly more detailed crash reports: We've also done a little work for automating symbolication (adding in names instead of numbers into crash reports), but that will probably be a while before we release something automated there. |
|
Our current belief is that this crash is related to The reason we haven't attacked this one yet, is we've not yet been able to reproduce it, but the stack traces are helpful, thank you! |
|
Hey @eseidel thanks for the updated info regarding the dSYM option to upload the symbols to Sentry. I just did that, downloaded the correct dSYM as described in the docs, and uploaded to Sentry via a fastlane plugin. It's registered inside Sentry: Sharing the new unsymbolicated stacktrace: |
|
Thanks! |
|
BTW, you'll notice that after uploading the .dSYM for flutter, you now see symbol information for Flutter symbols, e.g.: Which is cool, but in this case, since the crash is entirely in Dart code (App library), rather than Flutter, so the Flutter.dSYM doesn't tell you much. We have an internal tool @bryanoltman has been working on where we can match what you just sent against your cached release binary and fill in the symbols. We can try running that tomorrow and see if we can fill in the missing details for the crashing thread: |
|
Actually, there isn't enough information in that trace for us to do those lookups. Typically crash reports either have a "Binary Images" section at the bottom which show where libraries (like Flutter and App) are loaded, or they might include symbol-relative offsets, e.g. If Sentry offers a crash report that includes the "Binary Images" section (typically included in a raw .ips or .crash file) or you could make sentry symbolicate App symbols for you by uploading the App.dsym. We can figure out how to expose that in your Console for you if you don't have it cached. #1718 |
|
I am also facing the same issue.
stacktraceOS Version: iOS 14.3 (18C66) Exception Type: EXC_BAD_ACCESS (SIGBUS) Application Specific Information: Thread 6 Crashed: Thread 0 Thread 1 Thread 2 Thread 3 Thread 4 name: com.apple.uikit.eventfetch-thread Thread 5 Thread 6 name: io.flutter.1.ui Crashed: Thread 7 name: io.flutter.1.raster Thread 8 name: io.flutter.1.io Thread 9 name: io.worker.1 Thread 10 name: io.worker.2 Thread 11 name: io.worker.3 Thread 12 name: io.worker.4 Thread 13 name: io.worker.5 Thread 14 name: io.worker.6 Thread 15 name: dart:io EventHandler Thread 16 name: io.worker.1 Thread 17 name: io.worker.2 Thread 18 name: io.worker.3 Thread 19 name: io.worker.4 Thread 20 name: AVAudioSession Notify Thread Thread 21 Thread 22 name: com.google.firebase.crashlytics.MachExceptionServer Thread 23 Thread 25 name: DartWorker Thread 26 name: DartWorker Thread 27 Thread 28 name: SentryCrash Exception Handler (Secondary) Thread 30 name: io.sentry.app-hang-tracker Thread 31 name: com.apple.NSURLConnectionLoader Thread 32 name: DartWorker Thread 33 name: DartWorker Thread 34 name: DartWorker Thread 35 name: DartWorker Thread 36 name: DartWorker Thread 37 name: DartWorker Thread 38 name: DartWorker Thread 39 name: DartWorker Thread 6 crashed with ARM Thread State (64-bit): EOF |
|
Hey @eseidel ! Thank you for sharing in so much detail! It's really cool to get a better insight into what's what in the stacktraces. This one is with shorebird 0.25.2 |
|
Thank you very much for the report! After some help from another customer this morning we're now able to reproduce and we're working on reducing the failure and fixing! I hope we'll have a reduction within the next few hours and hopefully a fix tomorrow. 🤞 |
|
OK, we found the bug. This is the repro: main.dart: import 'a.dart';
Future<void> main() async {
await compute();
}a.dart: import 'b.dart' as b;
const Future<void> Function() compute = b.compute;b.dart Future<void> compute() async {
await Future.delayed(Duration.zero);
}It doesn't seem to crash upstream flutter, but it definitely crashes Shorebird. I think it's still causes incorrect execution in upstream flutter, just doesn't crash. We found it earlier in the day and filed as dart-lang/sdk#54860, but didn't realize it was also causing our crash! This happens to be triggered by package:dio, which is a relatively popular package. It could also be triggered by other packages, but I suspect almost all reports are from package:dio. |
|
Turns out we can't easily fix this for Flutter 3.16.9 because it requires a change to a part of Dart we don't currently use our forked copy for. So we're starting an upgrade to Dart 3.3.0 in anticipation of Flutter 3.19.0 presumably being soon after: |
|
We've prepared a release of Flutter 3.19.0-beta and Dart 3.3.0 for Monday. We decided it was better to move our Dart forward than trying to make more patches to work around this upstream bug. |
|
Thank you to the many who have helped and offered to help! We've built 3.19.0-beta and finished most of our pre-launch checks. We have a couple more to complete monday morning and then we'll launch. Dart 3.3.0 appears to be already pushed to stable, and my guess is that Flutter 3.19.0 will soon too, so we picked the Flutter 3.19.0-beta to ensure we depended on a recent enough Dart to include this upstream fix in it. Thank you all again for your patience. |
|
More context as to why we didn't fix this in our Dart for 3.16.9: Currently when you run Replacing the Dart SDK on downloads.shorebird.dev would be a little tricky. Our modified Dart SDK doesn't necessarily work for development / JIT workloads, since we only test it in the AOT / arm64 / iOS cases. So we'd want to either fix our SDK to ensure it worked for all JIT / command line workloads and test it. Or we'd want to build yet-another copy of Dart. In either case it would be sizable infrastructure work that we avoided by just updating our Dart dependency to the just-published-on-friday stable 3.3.0. |
|
We've landed the fix for this bug 🎉 As @eseidel mentioned, the fix required pulling in changes from upstream Dart so we've created a new Shorebird Flutter release which is based on the current beta (3.19.0-0.4.pre). To use the beta version we recommend switching to the Flutter beta channel and flutter channel beta
flutter upgradeOnce you've upgraded to the beta channel you can point shorebird to the beta release via: Finally you can create a new iOS release with the beta version: We expect a new stable Flutter release very soon and plan to publish a new stable Shorebird release as soon as Flutter 3.19.0 is out but in the meantime we believe this beta release fixes the crash. Let us know if you encounter any issues and we're more than happy to help! |
|
@eseidel @felangel Hey guys, I just updated shorebird to 0.26.0 and created a new iOS release. I'm happy to confirm that the app no longer experiecens a crash when I do the same exact steps of opening a single tab in my app where the response is bigger than 50Kb (yes I'm using dio). Awesome work, and many thanks! 🙌 |
Two crashes just came in for the same app:
These could happen when we end up on the CPU unwinding stacks which were made on the Simulator. I'm not yet sure why that would happen, but we've seen this kind of crash before.
The text was updated successfully, but these errors were encountered: