App crash due to a background call to `-[UIApplication applicationState]` in `-[SentryUIApplication init]`

[diogot]

Platform

tvOS

Environment

Other

Installed

Swift Package Manager

Version

8.23.0

Did it work on previous versions?

It works up to version 8.21.0

Steps to Reproduce

Call + (SentryId *)captureError:(NSError *)error withScopeBlock:(void (^)(SentryScope *_Nonnull))block in a background thread crashes the app due to Main Thread Checker: UI API called on a background thread: -[UIApplication applicationState].

This is happening in our unit tests, we didn't released to production. We are using Xcode 15.3.

Expected Result

App did not crash.

Actual Result

App crash with this stack trace:

Main Thread Checker: UI API called on a background thread: -[UIApplication applicationState] PID: 16779, TID: 3695907, Thread name: (none), Queue name: tv.standard.watch-NetworkService, QoS: 25 Backtrace: 4 Services 0x000000010842a4b4 -[SentryUIApplication init] + 244 5 Services 0x000000010841eacc -[SentryDependencyContainer application] + 68 6 Services 0x00000001083d32b4 -[SentryCrashWrapper enrichScope:] + 1096 7 Services 0x00000001083eafc8 -[SentryHub initWithClient:andScope:] + 736 8 Services 0x00000001084107e0 +[SentrySDK currentHub] + 60 9 Services 0x000000010841183c +[SentrySDK captureError:withScopeBlock:] + 80

Are you willing to submit a PR?

No response

[philipphofmann]

Thanks for reporting this, @diogot. This should be an easy fix.

There is no guarantee that SentryUIApplication init is called on the main thread. It usually gets called on the main thread like this:

-[SentryUIApplication init] at SentryUIApplication.m:31
-[SentryDependencyContainer application] at SentryDependencyContainer.m:261
-[SentryCrashWrapper enrichScope:] at SentryCrashWrapper.m:187
-[SentryHub initWithClient:andScope:] at SentryHub.m:80
+[SentrySDK startWithOptions:] at SentrySDK.m:209
+[SentrySDK startWithConfigureOptions:] at SentrySDK.m:249

But if for example the SDK gets started from a background thread or if somebody interacts with the hub without starting the SDK on a background thread, SentryUIApplication init might get called on a background thread.

@brustolin, could you please have a look?

[mlch911]

I'm experiencing this crash as well. When a network request is triggered in the background, the monitoring of the sentry network request can trigger this crash. I'm using sentry 8.23.0.

-[MaxWindow initWithFrame:] (MaxWindow.m:24)
-[AppDelegate window] (AppDelegate.m:184)
-[SentryUIApplication windows] (SentryUIApplication.m:84)
-[SentryCrashWrapper enrichScope:] (SentryCrashWrapper.m:187)
-[SentryHub initWithClient:andScope:] (SentryHub.m:80)
+[SentrySDK currentHub] (SentrySDK.m:76)
-[SentryRequestOperation initWithSession:request:completionHandler:]_block_invoke (SentryRequestOperation.m:37)

[kahest]

Thanks for the additional info @mlch911 we'll have a fix soon

[mlch911]

Thanks for the additional info @mlch911 we'll have a fix soon

I have commited a PR to fix this.

[diogot]

It seems that this was fixed in the main branch, it's great! Do you know when we'll have a new release?

[brustolin]

Hello @diogot, most likely until Thursday.

[diogot]

Awesome, thanks!

[diogot]

Hey, I tested with release 8.25.0 and I'm still experiencing crashes on my tests, here is the stack trace:

Thread 6 Crashed: 0 libsystem_kernel.dylib 0x1043913b0 __pthread_kill + 8 1 libsystem_pthread.dylib 0x103057124 pthread_kill + 256 2 libsystem_c.dylib 0x1802e35f4 abort + 100 3 libMainThreadChecker.dylib 0x103f9da44 ASSERT_API_MUST_BE_CALLED_FROM_MAIN_THREAD_FAILED + 872 4 libMainThreadChecker.dylib 0x103f9e5bc checker_c + 460 5 libMainThreadChecker.dylib 0x103f9d5ac trampoline_c + 72 6 libMainThreadChecker.dylib 0x103f5d37c handler_start + 52 7 Services 0x10610e5d4 -[SentryCrashWrapper enrichScope:] + 1120 8 Services 0x106126380 -[SentryHub initWithClient:andScope:] + 732 9 Services 0x10614eb18 +[SentrySDK currentHub] + 60 10 Services 0x10614fb74 +[SentrySDK captureError:withScopeBlock:] + 80

[diogot]

Should I open a new issues or this can be reopened?

[philipphofmann]

I reopened the issue @diogot. Thanks for reaching out to us again.

[diogot]

Tested on 8.26.0, the crash keeps happening:

Thread 5 Crashed: 0 libsystem_kernel.dylib 0x10654d3b0 __pthread_kill + 8 1 libsystem_pthread.dylib 0x1066f3124 pthread_kill + 256 2 libsystem_c.dylib 0x1802e35f4 abort + 100 3 libMainThreadChecker.dylib 0x10627da44 ASSERT_API_MUST_BE_CALLED_FROM_MAIN_THREAD_FAILED + 872 4 libMainThreadChecker.dylib 0x10627e5bc checker_c + 460 5 libMainThreadChecker.dylib 0x10627d5ac trampoline_c + 72 6 libMainThreadChecker.dylib 0x10623d37c handler_start + 52 7 Services 0x1086b2f34 -[SentryCrashWrapper enrichScope:] + 1120 8 Services 0x1086cb038 -[SentryHub initWithClient:andScope:] + 732 9 Services 0x1086f3b18 +[SentrySDK currentHub] + 68 10 Services 0x1086f4bbc +[SentrySDK captureError:withScopeBlock:] + 80

[diogot]

I looked at -[SentryCrashWrapper enrichScope:], I suspect that this is problem:

https://github.com/getsentry/sentry-cocoa/blob/fa1ec4470d0e9e94741a914e76767318077e01f2/Sources/Sentry/SentryCrashWrapper.m#L129

UIDevice is @MainActor, so calling this in a background thread will trap.

[brustolin]

This can happen (and will be fixed) if you're trying to use SentrySDK from a background thread before starting it.

Can you confirm this scenario @diogot?

[diogot]

We're observing this crash in our CI, now that I looked at the code, I found a workaround. I'm not running start in the simulator, but I'm calling capture. I'll change our code to do not call any method from the SDK while in the simulator. Should I leave this ticket open?

[brustolin]

Should I leave this ticket open?

Yes. We still need to fix this.

[JacobKingDev]

We use Sentry as our telemetry solution in a private SDK and one of our clients is seeing this bug exclusively under their UI test environment. They are putting pressure on us to get this resolved (and quite reasonably) as they aren't keen to put their application into production due to it consistently crashing in the synthetic test environment.

It's worth noting they (and we) are unable to reproduce the crash under normal organic app conditions, only when running UI tests, so I realise the impact is limited. However, commercially, we have a strong working relationship with this client that we very much want to uphold - this may mean we have to switch to an alternative telemetry solution if this bug doesn't get some attention. The issue has been open for nearly 4 months without much in the way of investigation.

[brustolin]

Hello @JacobKingDev. Can you confirm if it's possible that you're trying to use the SDK before calling SentrySDK.start?

[JacobKingDev]

Hello @JacobKingDev. Can you confirm if it's possible that you're trying to use the SDK before calling SentrySDK.start?

I can confirm that SentrySDK.start is the very first invocation we make to the SDK. It's called in the initialiser of the object that handles events. It's not possible to invoke the member functions on that class without first initialising the object.

[brustolin]

Thanks @JacobKingDev for the reply. This is a new case, we will need to investigate. Maybe it is related to the rest of the issue.

[philipphofmann]

@diogot the crash you pointed out in https://github.com/getsentry/sentry-cocoa/issues/3836#issuecomment-2110605384 is a different one and will be fixed with https://github.com/getsentry/sentry-cocoa/pull/4245. We can close this.