Philipp Hofmann

Yes, I think we should have enough information to fix it. Thanks for the update.

@nebsta, I'm sorry no, not yet. We didn't get to this yet.

We fixed the issue of the missing reference mentioned in https://github.com/getsentry/sentry-cocoa/issues/3977#issuecomment-2358020031 with https://github.com/getsentry/sentry-cocoa/issues/4050 shipped in 8.29.0. Now, we only need to fix this error. I bumped the priority for this,...

@nebsta, unfortunately, all the crashes I see in our internal SDK crash detection are before [8.13.1](https://github.com/getsentry/sentry-cocoa/blob/main/CHANGELOG.md#8131), in which we fixed a crash in `SentryTracer.finishInternal` with #3333. I can't reproduce the...

@nebsta, thanks for the update. Can you share a stacktrace of a crash on a simulator?

> The question is that if we don't finish a span/transaction, could there be issue here if we try to finish the same span/transaction when a previous one wasn't finished...

Thanks for opening the issue, @eric. We also see this in our [internal SDK crashes](https://sentry.sentry.io/issues/4680755648/?project=4505469596663808&query=is%3Aunresolved+backtrace&referrer=issue-stream&sort=user&statsPeriod=14d&stream_index=0).

@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...

> 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...

> @philipphofmann do you think we could change captureException to detect if the errors are NSException and use the callStackReturnAddresses like we do in SentryCrashMonitor_NSException.m? Yes, we can do that,...