sentry-cocoa: `[SentryTransactionContext getThreadInfo]` causes EXC_BAD_ACCESS - `getThreadInfo` attempted to dereference null pointer

Platform

macOS

Operating system: macOS 11.7.8(20G1351)
Model: MacBookPro11,3 (Intel)

Installed

Swift Package Manager

Version

8.9.4

Steps to Reproduce

  1. Use SentrySDK v8.9.4 in macOS application
  2. Initialise SentrySDK
  3. Call SentrySDK.startTransaction() (on main thread)
  4. The application may crash with EXC_BAD_ACCESS - getThreadInfo > attempted to dereference null pointer
SentrySDK.startTransaction(
    name: "InstallFlow",
    operation: #function,
    bindToScope: true
)

Expected Result

Application should not crash.

Actual Result

sentry::profiling::ThreadHandle::current() (in Acme) (SentryThreadHandle.cpp:49)
-[SentryTransactionContext getThreadInfo] (in Acme) (SentryTransactionContext.mm:127)
-[SentryTransactionContext commonInitWithName:source:parentSampled:] (in Acme) (SentryTransactionContext.mm:147)
-[SentryTransactionContext initWithName:nameSource:operation:origin:] (in Acme) (SentryTransactionContext.mm:64)
-[SentryHub startTransactionWithName:operation:bindToScope:] (in Acme) (SentryHub.m:323)
+[SentrySDK startTransactionWithName:operation:bindToScope:] (in Acme) (SentrySDK.m:200)
InstallFlow.start() (in Acme) (InstallFlow.swift:22)

Are you willing to submit a PR?

No response

About this issue

  • Original URL
  • State: open
  • Created 8 months ago
  • Reactions: 1
  • Comments: 24 (11 by maintainers)

Most upvoted comments

PS: Some of the customers affected by the crash in the release which used the 8.9.4 sentry told us this crash was fixed for them. We see this crash on our own laptop now so we can check&verify it more easily.

Thanks for reporting @jozefizso, we’ll investigate. (Internal reference.)

Sounds like we were able to fix a subset of the cases 🎉 but there’s still another issue. Looking again at the exception code, it mentions a null address. I should’ve inserted a null check on the value returned by pthread_mach_thread_np. Beyond that, we have no control over what that kernel call returns, so if it’s a null value we need to just try to gracefully fail instead of crashing.

The fix was released with 8.15.0.

Thanks a lot @armcknight. 🎆