Stack tracer is crashing during captureException

[kode54]

Platform

macOS

Environment

Production

Installed

Swift Package Manager

Version

8.46.0

Xcode Version

16.2

Did it work on previous versions?

No idea, this has happened a few times

Steps to Reproduce

1. App throws NSException during a work queue for tag reading
2. Exception is pushed to [SentrySDK captureException:]
3. App crashes

Expected Result

Exception should be logged, not sure if it should be fatal.

Actual Result

App crashes on this thread dump:

NSInvalidArgumentException: *** -[__NSArrayM insertObject:atIndex:]: object cannot be nil

Are you willing to submit a PR?

I am willing to submit a PR, if I can figure out where it went wrong.

[philprime]

Hi @kode54, thanks for reporting this.

Are you able to share a link to the Sentry issue so we can take a closer look at the crash data?

[kode54]

I'll have to give you an account on my self-hosted instance to access it.

[kode54]

Hmm, come to think of it, it may just be showing the stack trace from where I captured the exception, but the exception is correct for what was thrown by the @ try @ catch block. In this case, it was a NSString stringWithUTF8String being passed an invalid UTF-8 constant, and my fallback code not trying other string encodings, then some subsequent code attempting to assign the nil NSString* to an NSArray.

[philprime]

I actually just noticed the same behavior in a completely unrelated issue where the error was caught and the reported using Sentry.captureException at a different position in the code.

cc @philipphofmann would you say it is expected for the stack trace to point to the position where it was caught, rather than the stack trace of the original error that was caught?

internal case

[philipphofmann]

cc @philipphofmann would you say it is expected for the stack trace to point to the position where it was caught, rather than the stack trace of the original error that was caught?

Yes it is, but it often confuses users.

We have already removed those frames in the past, but then we sometimes remove too little or too much. It's complicated to remove the exact number of frames when you have no symbolication. Especially if the code changes. Then, we agreed on keeping the frames as it's also more accurate for letting the user know how we build the stacktrace. Some users actually complained that we removed the Sentry frames. We should document this somewhere so we don't have to keep writing this answer.

[philprime]

When using captureException the internal methods are also added to the stack grace, seemingly looking like it crashed in the SDK. We will improve this in getsentry/sentry#87076.

But in this case it looks like there might actually be an error occuring in buildStacktraceForCurrentThread so we'll investigate this.

[kode54]

Can we look instead at using the members of the NSException to build the stack trace?

https://developer.apple.com/documentation/foundation/nsexception?language=objc#1651286

It has callStackReturnAddresses and callStackSymbols.

[philprime]

@kode54 the NSException crash monitor should already use the callStackReturnAddresses here:

sentry-cocoa/Sources/SentryCrash/Recording/Monitors/SentryCrashMonitor_NSException.m

Lines 69 to 73 in fbb7656

	SENTRY_LOG_DEBUG(@"Filling out context.");
	NSArray *addresses = [exception callStackReturnAddresses];
	NSUInteger numFrames = addresses.count;
	uintptr_t *callstack = malloc(numFrames * sizeof(*callstack));
	assert(callstack != NULL);

There's also #741 where @philipphofmann recently brought up that the callStackReturnAddresses could be used for it.

[kode54]

What about if I'm catching the exception myself and passing it to captureException?

Edit: I'm getting a useless trace that starts from where captureException is called and ends at -[SentryStacktraceBuilder buildStacktraceForCurrentThread]