sentry-cocoa
sentry-cocoa copied to clipboard
getsentry
Shows unknown "Called from" stack frame in crash report
Environment
SaaS (https://sentry.io/)
Version
Sentry Cocoa 7.5.2
Steps to Reproduce
- Go to https://sentry.io/organizations/sindresorhus/issues/2833675135/events/8f9b4afd74da49fbb3e3fef911c4433e/
Expected Result
I expected to see the name of each stack frame.
Actual Result
The first stack frame is "unknown" and "redacted".
This is a macOS app using the SwiftUI App protocol.
Hey @sindresorhus, it seems like you didn't have the dSYMS uploaded for this event. I checked your issue, and the stacktrace looks fine.
I checked your issue, and the stacktrace looks fine.
Note that you have to switch to thread 0 in the stack trace section. The crash happened on thread 9.
Dato was correctly symbolicated and indeed the frames showed up. The code calling into it though, likely a system frame that didn't symbolicate. Did this event come from a Simulator? It possibly came in one a version of iOS that was brand new (even a beta release of iOS?), before we collected the system symbols so we didn't manage to symbolicate those frames? We had a bug in version ~6.0.x that could cause it too which doesn't seem to be the case if you're 7.5.2.
Usually, the bottom frame is something like libdyld +0x015f3c start. I just tried a crash with our macOS-Swift sample app on a M1 MacBook with macOS 12.1 and get the same result, see https://sentry.io/organizations/sentry-sdks/issues/2921695678/events/5b23f1fccbb4494d9ddd2bb37b133b5b/. So this is not related to SwiftUI. On macOS 11.6.1 https://sentry.io/organizations/sentry-sdks/issues/2921695678/events/f90d096dcfe54c978c4cde02eaf785db/ I get the bottom frame.
The unkown frame should be in libdyld. On macOS 11.6.1 the list of loaded images contains libdyld
but on macOS 12.1 libdyld is missing
It seems like SentryCrash is not able to retrieve information on libdyld when generating the crash report. Maybe something changed on macOS 12.1. The problem exists on both x86 and arm64 CPU architecture. @jan-auer will investigate if we also have this problem on the sentry-native SDK. As this issue is related to sentry-cocoa, I'm going to transfer this issue.
@jan-auer the logic for loading binary images is in SentryCrashDynamicLinker. The original file KSDynamicLinker doesn't contain any new patches that we don't have yet. I already applied the latest patch of accumulative patch with https://github.com/getsentry/sentry-cocoa/pull/1596.
Sorry, I made a mistake when looking at this the first time. libdyld is there in all cases, it's just unreferenced and the UI hides it. If you reset filters you'll find it.
This means, the bottom frame returned by the stack walker is either wrong, or it points at an image that's unloaded at the time of the crash. If you look at the address, it lies shortly after the Sentry framework, which suggests that this is a user-space library.
This issue has gone three weeks without activity. In another week, I will close it.
But! If you comment or otherwise update it, I will reset the clock, and if you label it Status: Backlog or Status: In Progress, I will leave it alone ... forever!
"A weed is but an unloved flower." ― Ella Wheeler Wilcox 🥀
![github-actions[bot] avatar](https://avatars.githubusercontent.com/in/15368?v=4 "Published by a pub.dev verified publisher"){kind=small}
No, not yet. We are going to discuss this again internally, as I also find it annoying, and we should fix it.
I still see this happening for our iOSSwift sample app
and for our macOS sample app: https://sentry-sdks.sentry.io/issues/4409194420/events/eca0ab201ffb4aa79ca342b207eebfaa/
cc @kahest and @brustolin, we need look into this.
We'll have a look again at the root cause. If there is no pragmatic/reasonable way to solve this we may look at custom rules to not show this specific frame since it doesn't provide any value.
