Incorrect line number information in crash reports for a Swift runtime failure

[mattstevens]

[REQUIRED] Step 1: Describe your environment

• Xcode version: 12.5
• Firebase SDK version: 8.1.0
• Installation method: CocoaPods
• Firebase Component: Crashlytics

[REQUIRED] Step 2: Describe the problem

I've noticed that crash reports resulting from a force-unwrap of an Optional with a nil value do not have correct line number information, at least for our app. Here's an example:

EXC_BREAKPOINT 0x0000000105069278

Crashed: Main  
0  Some App                       0x105069278 closure #2 in SpaceContentViewController.viewWillTransition(to:with:) + 4344844920 (SpaceContentViewController.swift:4344844920)
1  Some App                       0x1050f1628 thunk for @escaping @callee_guaranteed (@guaranteed UIViewControllerTransitionCoordinatorContext) -> () + 4345402920 (<compiler-generated>:4345402920)

Here's what a crash report from App Store Connect shows for the same crash:

Thread 0 Crashed:
0   Some App                      0x0000000105069278 Swift runtime failure: Unexpectedly found nil while unwrapping an Optional value + 0 (SpaceContentViewController.swift:0)
1   Some App                      0x0000000105069278 closure #2 in SpaceContentViewController.viewWillTransition(to:with:) + 1624 (SpaceContentViewController.swift:184)
2   Some App                      0x00000001050f1628 thunk for @escaping @callee_guaranteed (@guaranteed UIViewControllerTransitionCoordinatorContext) -> () + 40 (<compiler-generated>:0)

If I calculate the load address for our binary in the Crashlytics report and then manually symbolicate against the dSYM that was uploaded to Crashlytics I get the same information as Apple's report:

$ atos -o "dSYMs/SomeApp.app.dSYM/Contents/Resources/DWARF/SomeApp" -arch arm64 --inlineFrames -l 0x104F64000 0x105069278 0x1050f1628

Swift runtime failure: Unexpectedly found nil while unwrapping an Optional value (in Some App) (SpaceContentViewController.swift:0)
closure #2 in SpaceContentViewController.viewWillTransition(to:with:) (in Some App) (SpaceContentViewController.swift:184)
thunk for @escaping @callee_guaranteed (@guaranteed UIViewControllerTransitionCoordinatorContext) -> () (in Some App) (<compiler-generated>:0)

Another way this problem presents is that the Crashlytics report has line number information that appears valid at first glance, but is pointing somewhere other than the line where the force-unwrap occured. Sometimes this is obviously off, like a line number at the end of a function, but other times it is misleading, pointing at a line that seems like it could be the cause of the crash but isn't. In these cases Apple reports and manual symbolication also point to the line where the force-unwrap occurred.

[rizafran]

Hi @mattstevens. Is the issue reproducible using the latest SDK version (8.6.1)? Also, make sure that there are no missing dSYMs in your dashboard to properly deobfuscate your crash reports. Thanks.

[google-oss-bot]

Hey @mattstevens. We need more information to resolve this issue but there hasn't been an update in 5 weekdays. I'm marking the issue as stale and if there are no new updates in the next 5 days I will close it automatically.

If you have more information that will help us get to the bottom of this, just add a comment!

[mattstevens]

I'm able to reproduce the issue with SDK version 8.6.1, and I've confirmed that no missing dSYMs are reported for this build. As before if I manually symbolicate against the dSYM that was uploaded to Crashlytics I get accurate line number information.

[rizafran]

Thanks for sharing your findings, @mattstevens. I've discussed this with the team, and we've filed an internal bug (b/200064220) in order to investigate what's causing it.