getsentry / sentry-cocoa

The official Sentry SDK for iOS, tvOS, macOS, watchOS.
https://sentry.io/for/cocoa/
MIT License
797 stars 315 forks source link

C++ exception is not nicely displayed as stack lines in the UI #1562

Open sindresorhus opened 2 years ago

sindresorhus commented 2 years ago

Environment

SaaS (https://sentry.io/)

Version

Sentry Cocoa 7.5.2

Steps to Reproduce

Expected Result

I expected to see the stack trace lines with UI styling.

Actual Result

Instead it just shows a stack line referencing CPPExceptionTerminate. The stack trace is just plain text in the error description field.

Screen Shot 2021-12-03 at 12 57 55

Example report: https://sentry.io/organizations/sindresorhus/issues/2771169314/events/3a1f359eac1e494eae2b877e978368ad/

getsentry-release commented 2 years ago

Routing to @getsentry/team-mobile for triage. ⏲️

philipphofmann commented 2 years ago

When throwing a CPP Exception in a macOS sample app the problem report displays a similar stack trace as Sentry:

Application Specific Information:
abort() called
terminating with uncaught exception of type std::invalid_argument: Invalid Argument.

Thread 0 Crashed:: Dispatch queue: com.apple.main-thread
0   libsystem_kernel.dylib          0x00007fff203b492e __pthread_kill + 10
1   libsystem_pthread.dylib         0x00007fff203e35bd pthread_kill + 263
2   libsystem_c.dylib               0x00007fff20338406 abort + 125
3   libc++abi.dylib                 0x00007fff203a6ef2 abort_message + 241
4   libc++abi.dylib                 0x00007fff203985e5 demangling_terminate_handler() + 242
5   libobjc.A.dylib                 0x00007fff20291595 _objc_terminate() + 104
6   io.sentry.Sentry                0x000000010b894193 CPPExceptionTerminate() + 2291 (SentryCrashMonitor_CPPException.cpp:169)
7   libc++abi.dylib                 0x00007fff203a6307 std::__terminate(void (*)()) + 8
8   libc++abi.dylib                 0x00007fff203a8dd1 __cxa_rethrow + 99
9   libobjc.A.dylib                 0x00007fff2028f110 objc_exception_rethrow + 37
10  com.apple.AppKit                0x00007fff23142c29 -[NSApplication _handleEvent:] + 137
11  com.apple.AppKit                0x00007fff22cd2c8e -[NSApplication run] + 623
12  com.apple.AppKit                0x00007fff22ca6e6c NSApplicationMain + 816
13  io.sentry.macOS-Swift           0x000000010b839f89 main + 9 (AppDelegate.swift:5)
14  libdyld.dylib                   0x00007fff203fef3d start + 1

Just to get it right @sindresorhus, you would like to see the stack trace of the CPP code? What is your project setup?

sindresorhus commented 2 years ago

Just to get it right @sindresorhus, you would like to see the stack trace of the CPP code?

I already see the stack trace of the C++ code, but it's in the error message instead of Sentry's stack frames UI. I expected it to be nicely formatted like other exceptions.

What is your project setup?

Not sure what info you're looking for. It's a macOS app built with SwiftUI. The exception is coming from Apple's frameworks, not the app. See the linked event and screenshot.

philipphofmann commented 2 years ago

Ah, now, I get your point, @sindresorhus. It seems like the JSON contains a valid stacktrace, but the UI is not displaying it correctly. @priscilawebdev, could you maybe have a look at this sample event and check out why we don't display a proper stacktrace?

priscilawebdev commented 2 years ago

sure! I'll have a look into it

priscilawebdev commented 2 years ago

When changing the filter from "App only" to "Full", the frames mentioned in the message are being displayed:

libdispatch +0x016708 _dispatch_workloop_worker_thread libsystem_pthread +0x0035b0 _pthread_wqthread

By default, the UI displays app-only frames (in_app = true) and these have the property equal to false in the provided event.

The message displayed at the top of stack traces is just a plain string that came from the JSON property value and the UI doesn't format it.

in this case, if you want to display more frames in the stack trace list, these have to be listed under stacktrace -> frames

You can find more information about our Exception interface in our documentation https://develop.sentry.dev/sdk/event-payloads/exception/

philipphofmann commented 2 years ago

Ah, I see the following is the value of the exception and is coming from the SDK.

0x00000001c1fd2ea4 _dispatch_lane_invoke + 392
32  libdispatch.dylib                   0x00000001c1fdd708 _dispatch_workloop_worker_thread + 656
33  libsystem_pthread.dylib             0x00000001c21855b0 _pthread_wqthread + 288
34  libsystem_pthread.dylib             0x00000001c21842c4 start_wqthread + 8 > _crashOnException: > callStackSymbols > ntrollerDelegate

That doesn't really make sense. I will move this to the Cocoa SDK to fix this.

philipphofmann commented 2 years ago

It could be that we need to fix this problem somewhere here https://github.com/getsentry/sentry-cocoa/blob/229c663f6bdf225f8ef855f8355d48196a022cb8/Sources/Sentry/SentryCrashReportConverter.m#L347-L351

github-actions[bot] commented 2 years ago

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 🥀

ainopara commented 2 years ago
ScreenShot-2022-03-25-3659 ScreenShot-2022-03-25-3660

I have same issue. When sentry sdk report a NSException caused crash, most useful information was lost. It seems an regression.

ScreenShot-2022-03-25-3663