'EXC_BREAKPOINT with very large line number value in crashlytics swift/ios
I am getting a worrying amount of EXC_BREAKPOINT crashes in crashlytics for my iOS swift app.
I tried fixing the bug by looking at the method 'populate(user:withLegacyUsage:)' and making sure my optional are correctly unwrapped. In this method I was also removing elements in an array while I was looping over that array. I thought that might have caused the error, but the error still happens after uploading my patched build.
I guess I have two questions:
Why are some of the crashing line numbers so extremely large? "+ 4304075872" is not possible to be a line in my app. I don't have that much code. Does this mean there is some kind of loop going on? Might this be the issue? Or is this normal?
How to deal with EXC_BREAKPOINTS crashes in general? How - looking at the stack trace - can I have a better understanding of where the crash occurs? Is it residing at a more low-level place? Does it have to do with memory leaks? Retain cycles? I am lost.
Thank you for any tips or help!
Crashed: com.apple.main-thread
0 myAppName 0x1008d3c60 closure #3 in UserManager.populate(user:withLegacyUsage:) + 4304075872 (<compiler-generated>:4304075872)
1 myAppName 0x1008d6c74 specialized UserManager.populate(user:withLegacyUsage:) + 4304088180 (<compiler-generated>:4304088180)
2 myAppName 0x1008d3664 closure #1 in UserManager.loadLegacyUsers(withCompletionHandler:) + 129 (UserManager.swift:129)
3 myAppName 0x1008f0f34 closure #1 in LoginViewController.viewDidLoad() + 4304195380 (<compiler-generated>:4304195380)
4 myAppName 0x1008f39cc partial apply for closure #1 in LoginViewController.playIntroAnimation(withCompletionHandler:) + 4304206284 (<compiler-generated>:4304206284)
5 myAppName 0x1008c9e90 partial apply for closure #1 in AnimationManager.playAnimation(inView:withCompletionHandler:) + 4304035472 (<compiler-generated>:4304035472)
6 Lottie 0x101315b78 $s6Lottie27AnimationCompletionDelegateC16animationDidStop_8finishedySo11CAAnimationC_SbtF + 416
7 Lottie 0x101315bec $s6Lottie27AnimationCompletionDelegateC16animationDidStop_8finishedySo11CAAnimationC_SbtFTo + 64
8 QuartzCore 0x18d6efdac CA::Layer::run_animation_callbacks(void*) + 276
9 libdispatch.dylib 0x186927184 _dispatch_client_callout + 16
10 libdispatch.dylib 0x1868d9190 _dispatch_main_queue_callback_4CF$VARIANT$mp + 1044
11 CoreFoundation 0x186bd85e4 __CFRUNLOOP_IS_SERVICING_THE_MAIN_DISPATCH_QUEUE__ + 12
12 CoreFoundation 0x186bd35d8 __CFRunLoopRun + 2004
13 CoreFoundation 0x186bd2adc CFRunLoopRunSpecific + 464
14 GraphicsServices 0x190b73328 GSEventRunModal + 104
15 UIKitCore 0x18ace063c UIApplicationMain + 1936
16 myAppName 0x100875110 main + 12 (AppDelegate.swift:12)
17 libdyld.dylib 0x186a5c360 start + 4
Solution 1:[1]
Those are likely not line numbers but rather memory addresses. Going down the list of "function + x" in that stacktrace they're all multiples of 4 as well which points to memory addresses. The reason this happens is because Apple autogenerates code for Swift. Generally, when you see "+ something", it usually means the crash was symbolicated on-device, which is able to pick up those generated code lines.
This link to Apple's technical docs might have more information, with stacktrace examples under the "Determining Whether a Crash Report is Symbolicated" section.
Solution 2:[2]
I have the same problem with Firebase Crashlytics. And sometimes it does not even give you the top level information of the crash. It directly skips to the lower levels so you can't tell where it originates.
I've added the Sentry crash logger alongside Firebase Crashlytics to our app and it seems to better so far. It gives the right line number and also has breadcrumbs leading to the crash by default which is quite helpful.
Sources
This article follows the attribution requirements of Stack Overflow and is licensed under CC BY-SA 3.0.
Source: Stack Overflow
| Solution | Source |
|---|---|
| Solution 1 | Kevin Kokomani |
| Solution 2 | Devenom |