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

[kostik15]

Description

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: Firebase Crashlytics logs:

Crashed: com.apple.main-thread
0  UltimaPayments                 0x66f30 tryLogin + 4306546480 (ReauthorizationViewController.swift:4306546480)
1  UltimaPayments                 0x66754 @objc ReauthorizationViewController.loginButtonTapped(_:) + 4306544468
2  UIKitCore                      0x4c8a98 -[UIApplication sendAction:to:from:forEvent:] + 100
3  UIKitCore                      0x5f4db8 -[UIControl sendAction:to:forEvent:] + 128
4  UIKitCore                      0x36ff90 -[UIControl _sendActionsForEvents:withEvent:] + 352

Crashed: com.apple.main-thread
0  UltimaPayments                 0x60f8c viewWillAppear + 4368338828 (TransactionsListViewController.swift:4368338828)
1  UltimaPayments                 0x60fcc viewWillAppear + 4368338892 (<compiler-generated>:4368338892)
2  UIKitCore                      0x1ab288 -[UIViewController _setViewAppearState:isAnimating:] + 664
3  UIKitCore                      0x2d952c -[UIViewController __viewWillAppear:] + 120

Same crashes in Xcode Organizer

Thread 0 name:
Thread 0 Crashed:
0   UltimaPayments                	0x00000001049e2f30 Swift runtime failure: Unexpectedly found nil while implicitly unwrapping an Optional value + 0 (ReauthorizationViewController.swift:0)
1   UltimaPayments                	0x00000001049e2f30 ReauthorizationViewController.tryLogin() + 1968 (ReauthorizationViewController.swift:129)
2   UltimaPayments                	0x00000001049e28e8 ReauthorizationViewController.tryLogin() + 360 (ReauthorizationViewController.swift:0)
3   UltimaPayments                	0x00000001049e2754 @objc ReauthorizationViewController.loginButtonTapped(_:) + 60
4   UIKitCore                     	0x00000001834c5a98 -[UIApplication sendAction:to:from:forEvent:] + 100 (UIApplication.m:53

Thread 0 name:
Thread 0 Crashed:
0   UltimaPayments                	0x000000010500cf8c Swift runtime failure: Unexpectedly found nil while implicitly unwrapping an Optional value + 0 (TransactionsListViewController.swift:0)
1   UltimaPayments                	0x000000010500cf8c TransactionsListViewController.viewWillAppear(_:) + 1420 (TransactionsListViewController.swift:46)
2   UltimaPayments                	0x000000010500cb00 selectedAccountView.get + 16 (TransactionsListViewController.swift:0)
3   UltimaPayments                	0x000000010500cb00 TransactionsListViewController.viewWillAppear(_:) + 256
4   UltimaPayments                	0x000000010500cfcc @objc TransactionsListViewController.viewWillAppear(_:) + 40 (<compiler-

This bug is same problem as was here: https://github.com/firebase/firebase-ios-sdk/issues/8594

Reproducing the issue

No response

Firebase SDK Version

9.4.1

Xcode Version

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

[rizafran]

Thanks for reporting, @kostik15. I'll inform the team about this in the internal bug and see what we can do.

[dhoerl]

Interesting - I just saw this. Having a similar issue with my app - crashes in Swift files often have bizarre line numbers (in the tens of thousands). But this is at least a hint - likely forced unwrap - give me a hint where to look now!

[oskarsliukis]

Any info for this? Seems that line numbers are being reported wrong since Xcode 14.

[dhoerl]

Any info for this? Seems that line numbers are being reported wrong since Xcode 14.

Note its broken in Xcode 13 as well. We started seeing this after adding a bunch of new Swift code to our mostly Objective-C project.

[ByronCoffinV]

Any updates on this? we are experiencing the same issue and need to know where the crash is originating from

[rastaman111]

I noticed that this failure occurs not for the first year, and it is unrealistic to understand where the application breaks

[HendSalahEldlin]

I have the same issue, any solution please @rizafran

[rizafran]

Hi all, sorry for the trouble. I'll make a follow up to the team regarding this issue and will let you know once I got an update.

[samedson]

Hey folks, thank you for reporting this. We're looking into the discrepancy, but haven't gotten to the bottom of it.

We've found that the atos command line utility produces results the same as Xcode Organizer's. Crashlytics just reads what's in the dSYM, so we're still figuring out why there seems to be more accuracy on Apple's side.

Eg. this command can produce the correct line numbers:

atos -o "dSYMs/SomeApp.app.dSYM/Contents/Resources/DWARF/SomeApp" -arch arm64 --inlineFrames -l <addresses, eg: "0x104F64000 0x105069278 0x1050f1628">

One thing that may be worth trying is uploading the symbols to the Crashlytics web dSYM uploader, and seeing if it produces different results. That system processes symbols differently and may yield better results. You can find that uploader on the Crashlytics Missing dSYMs page in the Firebase Console. You can drag and drop a zip of dSYMs there.

[themiswang]

Hey folks, if you are facing this issue now would be much appreciated to send a report through Firebase support including the related dsym file and stack trace. I am currently investigating on a potential solution on how to get more accurate information for the crashes happen at compiler-generated lines. Would be really helpful if we can get more examples to try out and validate the solution. Thank you!

[rodmaz]

Any update on this? This is a really critical issue leaving us unable to properly debug apps.

[themiswang]

Hey folks,

We have recently launched the new feature for Swift compiler-generated frame symbolication improvement. We now more accurately convert compiler-generated Swift frames to a file and line number so that it’s easier to understand stack traces and debug issues.

[themiswang]

Close this issue since feature has successfully launched. If you have any other issues feel free to open a new issue or contact Firebase Support.

[kennywyland]

@themiswang I still experienced this with a crash that happened yesterday:

Crashed: com.apple.main-thread 0 HerdBoss 0x143cf4 SemenManagerLocationDetailListViewController.viewDidLoad() + 4365761780 (:4365761780) 1 HerdBoss 0x143d18 @objc SemenManagerLocationDetailListViewController.viewDidLoad() + 4365761816 (:4365761816) 2 UIKitCore 0x37e088 -[UIViewController _sendViewDidLoadWithAppearanceProxyObjectTaggingEnabled] + 84

I'm not sure if this helps you find the issue to be able to investigate, but here is the url when I view the issue.

[rodmaz]

Yeah, we also still see this problem even w/ the latest versions. @themiswang Why has this issue been closed? In which version of Firebase is this fixed?

[themiswang]

Hey @rodmaz, @kennywyland,

It is a fix on our backend. For context for some of the <compiler-generated> lines we are able to find source file and line number information. So the case of incorrect line number generated by <compiler-generated> should get reduced. For this issue seems like it is mixed <compiler-generated> with other forms of incorrect line number. Let's create a new issue and target the remaining issue for folks with more specific description. And would be nice if you can file a bug to Firebase Support with the dSYM related to the crash and I am happy to take a look.

Before fix:

After fix:

[oskarsliukis]

I'm also experiencing this issue, even after backend fix. Is there a new ticket / issue opened for this?

[kennywyland]

@themiswang I just filed a bug: 10232560