[Crashlytics] Developer has ability to mark framework ownership

[lilidotshi]

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

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]

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

[Lyokone]

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

[lilidotshi]

@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.

[lilidotshi]

If I disable Enable Debug Dylib support, i still get this:

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

[lilidotshi]

@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.

[themiswang]

Hey @lilidotshi,

Thank you for reaching out and providing the reproducible sample app. I did take a look this week and this is probably work as intend. Essentially, the dynamic framework is being treated as a 3rd party library because it's not in the main app's compilation stage.

The reason you can see it marks as blamed for such frame in simulator is because that on simulator framework symbols are not completely removed. We can still extract symbol information from simulator runtime while crash happening. So on backend we are able to mark such frame as developer frame. But when build on a real device, dynamic framework symbols are completely redacted so it is treated as a 3rd party library.

For some potential solutions I wonder if you could include that library's code directly, or make as a static library instead to see if it solves the problem?

[lilidotshi]

@themiswang thank you for your response!

I think even if we have actual third party libraries, there's an argument here for being able to bucket correctly, eg being able to group third party bugs in one place as opposed to split up across multiple parts of the app. I can try a static framework to see how that works, but the way we've designed our app is such that we have modules, and thus depend on dynamic linking for shared pieces of code.