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

Crashlytics no longer bucketing correctly for builds to device #14218

Open
lilidotshi opened this issue Dec 6, 2024 · 5 comments
Open

Crashlytics no longer bucketing correctly for builds to device #14218

lilidotshi opened this issue Dec 6, 2024 · 5 comments

Comments

@lilidotshi
Copy link

lilidotshi commented Dec 6, 2024

Description

I'm running into an issue where it looks like both fatal and non-fatals are not being bucketed correctly, but only when i build to a device. I have an app that references another dynamic framework of mine, where I'm calling fatalError("some message"). I also tried with non-fatals with the same effect. In the simulator, these crashes/nonfatals are logged correctly (see images below). However, with the same code, and same build settings, building to an actual device logs the issue as part of the main app as opposed to the dylib. This is causing everything to be bucketed together across my various modules, which is bad because I can't identify individual crashes easily from the dash.

I've heard there are issues with the Enable Debug dylib support setting but that's off for me.

Simulator Device
Screenshot 2024-12-05 at 11 53 25 AM Screenshot 2024-12-05 at 11 53 35 AM

Reproducing the issue

Create a vanilla SwiftUI app, and a dynamic framework. Have the app depend on the framework and call fatalError somewhere within the framework. On a simulator, crash stacktrace looks good and buckets correctly. On a device it buckets incorrectly and is all bucketed within App.main and greyed out stack traces to the actual crash

Firebase SDK Version

11.6.0

Xcode Version

16.1

Installation Method

Swift Package Manager

Firebase Product(s)

Crashlytics

Targeted Platforms

iOS

Relevant Log Output

No response

If using Swift Package Manager, the project's Package.resolved

Expand Package.resolved snippet
Replace this line with the contents of your Package.resolved.

If using CocoaPods, the project's Podfile.lock

Expand Podfile.lock snippet
Replace this line with the contents of your Podfile.lock!
@google-oss-bot
Copy link

I couldn't figure out how to label this issue, so I've labeled it for a human to triage. Hang tight.

@Lyokone
Copy link

Lyokone commented Dec 10, 2024

Hello @lilidotshi could you provide a complete sample in a separate repository so I can reproduce this? Thanks

@lilidotshi
Copy link
Author

@Lyokone here you go: https://github.com/lilidotshi/CrashlyticsDemo

Copy your own google-service.plist file into ConfigurationFiles/development/, and when you run it, run the DemoApp-Debug scheme on an actual device. When the app launches, tap Show Menu and then Crash. This is what's coming up in firebase for me. You can see that where the crash actually happened is grayed out.

Screenshot 2024-12-10 at 11 36 16 AM
Screenshot 2024-12-10 at 11 36 12 AM
Screenshot 2024-12-10 at 11 35 58 AM

@lilidotshi
Copy link
Author

lilidotshi commented Dec 10, 2024

If I disable Enable Debug Dylib support, i still get this:
Screenshot 2024-12-10 at 11 41 14 AM
Screenshot 2024-12-10 at 11 41 34 AM
Screenshot 2024-12-10 at 11 41 53 AM

Conversely, if you run the demo app on a simulator and crash it from the menu, this is what firebase produces:

Screenshot 2024-12-10 at 11 45 24 AM
Screenshot 2024-12-10 at 11 45 30 AM

@lilidotshi
Copy link
Author

lilidotshi commented Dec 17, 2024

@Lyokone do you need any more info from me? This is a blocking issue for us using Firebase if we can't get properly symbolicated crashes.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

4 participants