sentry::profiling::backtrace SEGV

[eric]

Platform

iPadOS

Environment

TestFlight

Installed

CocoaPods

Version

8.26.0

Xcode Version

15.4

Did it work on previous versions?

No response

Steps to Reproduce

Eventually it crashes.

Expected Result

It not crash.

Actual Result

OS Version: iOS 17.5 (21O5587a)
Report Version: 104

Exception Type: EXC_BAD_ACCESS (SIGSEGV)
Exception Codes: SEGV_NOOP at 0x000000016f1abf68
Crashed Thread: 39

Application Specific Information:
Exception 1, Code 1, Subcode 6158991208 >
KERN_INVALID_ADDRESS at 0x16f1abf68.

Thread 39 Crashed:
0   Sentry                          0x104d61e64         sentry::profiling::backtrace (SentryBacktrace.cpp:85)
1   Sentry                          0x104d62088         sentry::profiling::enumerateBacktracesForAllThreads (SentryBacktrace.cpp:159)
2   Sentry                          0x104dc23ac         sentry::profiling::(anonymous namespace)::samplingThreadMain (SentrySamplingProfiler.cpp:67)
3   libsystem_pthread.dylib         0x47baa948c         _pthread_start

Thread 39 crashed with ARM Thread State (64-bit):
    x0: 0x0000000000000000   x1: 0x0000000308bd5350   x2: 0xfffffffffffffff0   x3: 0x000000016e97a770
    x4: 0xffffffffffffeb68   x5: 0x0000000000000020   x6: 0x0000000000001470   x7: 0x0000000000000000
    x8: 0x000000016f1abf60   x9: 0x000000016f12c000  x10: 0x0000000000000001  x11: 0x000000016e97aa20
   x12: 0x00000000000007fb  x13: 0x00000000000007fd  x14: 0x00000000ae25a064  x15: 0x0000000000000064
   x16: 0xffffffffffffffd1  x17: 0x00000000000005b9  x18: 0x0000000000000000  x19: 0x000000016e97aa4f
   x20: 0x0000000000000080  x21: 0x000000016e97aa50  x22: 0x000000016e97aaf0  x23: 0x0000000308bd5350
   x24: 0x0000000308bd5c60  x25: 0x0000000000000000  x26: 0x0000000000000001  x27: 0x000000016e97aa90
   x28: 0x000000016e97aa68   fp: 0x000000016e97aa20   lr: 0x0000000104d61e24   sp: 0x000000016e97a690
    pc: 0x0000000104d61e64 cpsr: 0x0000000080001000

Are you willing to submit a PR?

No response

┆Issue is synchronized with this Jira Improvement by Unito

[philipphofmann]

Thanks for opening the issue, @eric. We also see this in our internal SDK crashes.

[bb-git]

How critical is this issue, as we would like to update to the letest version and what triggers it?

[philipphofmann]

@bb-git, we haven't investigated what causes this yet. We see that this has happened from time to time for all SDK versions since 8.3.3. So, I guess updating to any version later than 8.3.3 shouldn't make much of a difference.

[dachakra]

Hi, I have a customer experiencing the same crash. Here's the stacktrace:

Signal: SIGSEGV
EXC_BAD_ACCESS (SIGSEGV): EXC_BAD_ACCESS (SIGSEGV)
Sentry
sentry::profiling::backtrace(sentry::profiling::ThreadHandle const&, sentry::profiling::ThreadHandle const&, unsigned long*, sentry::profiling::StackBounds const&, bool*, unsigned long, unsigned long) (SentryBacktrace.cpp:85) 
Sentry
sentry::profiling::backtrace(sentry::profiling::ThreadHandle const&, sentry::profiling::ThreadHandle const&, unsigned long*, sentry::profiling::StackBounds const&, bool*, unsigned long, unsigned long) (SentryBacktrace.cpp:66) 
Sentry
sentry::profiling::enumerateBacktracesForAllThreads(std::__1::function<void (sentry::profiling::Backtrace const&)> const&, std::__1::shared_ptr<sentry::profiling::ThreadMetadataCache> const&) (SentryBacktrace.cpp:159) 
Sentry
sentry::profiling::(anonymous namespace)::samplingThreadMain(void*) (SentrySamplingProfiler.cpp:54) 
libsystem_pthread.dylib
_pthread_start + 136

The crash is affecting 0.2% of the users, mostly running on iPhone devices. Running Sentry React Native SDK 5.22.3 which runs cocoa 8.26.0. We couldn't reproduce locally. Any advise on debugging?

[cstavitsky]

@philipphofmann I have another customer experiencing a similar crash. Currently happening to a low number of users because Sentry is rolled out only to a low number of users, but concerned that this might grow significantly when Sentry is rolled out to all users.

// sentry.cocoa v 8.30.0

EXC_BAD_ACCESS
zeAnimation >
KERN_INVALID_ADDRESS at [...........].

signal: SIGSEGV (SEGV_NOOP)

Sentry sentry::profiling::backtrace(sentry::profiling::ThreadHandle const&, sentry::profiling::ThreadHandle const&, unsigned long*, sentry::profiling::StackBounds const&, bool*, unsigned long, unsigned long) (SentryBacktrace.cpp:85)
Sentry
sentry::profiling::enumerateBacktracesForAllThreads(std::__1::function<void (sentry::profiling::Backtrace const&)> const&, std::__1::shared_ptr<sentry::profiling::ThreadMetadataCache> const&) (SentryBacktrace.cpp:155)
Sentry
sentry::profiling::(anonymous namespace)::samplingThreadMain(void*) (SentrySamplingProfiler.cpp:67)
libsystem_pthread
_pthread_start

[kahest]

fyi @armcknight ^

[armcknight]

Just to update on what is happening in this code: we get thread information from thread_get_state(...) in mach/thread_act.h, which includes pointers to memory locations that contain the backtrace frame information for the thread. In some cases, that data is invalid, so when we dereference it in SentryBacktrace.cpp line 85 to get the next frame as we unwind, the program crashes.

We're still investigating how to better validate these pointers. Currently we just look at whether or not it lies within the stack boundaries. We could potentially do something more involved like testing whether the memory is actually readable, but even that may still not tell is whether the contents of that memory location actually match the structure we want to use.