braze-inc / braze-swift-sdk

Braze SDK for the Apple ecosystem, including: iOS, macOS, iPadOS, visionOS, tvOS
https://www.braze.com
Other
52 stars 19 forks source link

[Bug]: App Hanging when starting Braze SDK on Mac Catalyst #60

Closed Shakarang closed 1 year ago

Shakarang commented 1 year ago

Platform

Mac Catalyst

Platform Version

macOS 12 / macOS 13

Braze SDK Version

5.13.0

Xcode Version

14.3

Computer Processor

Intel

Repro Rate

100%

Steps To Reproduce

Example:

  1. Initialise the Braze SDK using any configuration

Expected Behavior

No App Hang is reported.

Actual Incorrect Behavior

The Application Hangs on macOS devices

Verbose Logs

libsystem_kernel    0x7ff80661f9a6 semaphore_wait_trap
libdispatch         0x7ff8064a5c9c _dispatch_semaphore_wait_slow
OurApplication            0x00010262e298 AsyncViewStore.executeSync
OurApplication            0x00010262d99f BrazeViewStore.start
OurApplication            0x00010262d6d5 BrazeViewStore.enabled.setter
OurApplication            0x000102627e72 Braze.enabled.setter
OurApplication            0x000102629833 Braze.init
OurApplication            0x00010249d061 Braze.__allocating_init (<compiler-generated>)
OurApplication            0x00010249d061 BrazeService.init (BrazeService.swift:48)
OurApplication            0x0001011c4668 BrazeService.__allocating_init (<compiler-generated>)
OurApplication            0x0001011c4668 AppServicesContainer.init (AppServicesContainer.swift:111)
OurApplication            0x0001011ac2f9 AppServicesContainer.__allocating_init (AppServicesContainer.swift)
OurApplication            0x0001011ac2f9 AppCoordinator.init (AppCoordinator.swift:76)
OurApplication            0x0001012b7b2b AppCoordinator.__allocating_init (<compiler-generated>)
OurApplication            0x0001012b7b2b SceneDelegate.scene (SceneDelegate.swift:33)
OurApplication            0x0001012b73b1 SceneDelegate.scene (<compiler-generated>)
OurApplication            0x0001012b73b1 SceneDelegate.scene (<compiler-generated>:17)
UIKitCore           0x7ff914727de6 +[UIScene _sceneForFBSScene:create:withSession:connectionOptions:]
UIKitCore           0x7ff914726176 -[UIApplication _connectUISceneFromFBSScene:transitionContext:]
UIKitCore           0x7ff914724e5a -[UIApplication workspace:didCreateScene:withTransitionContext:completion:]
UIKitCore           0x7ff914724c93 -[UIApplicationSceneClientAgent scene:didInitializeWithEvent:completion:]
FrontBoardServices  0x7ff81946b7b4 -[FBSScene _callOutQueue_agent_didCreateWithTransitionContext:completion:]
FrontBoardServices  0x7ff81948d272 __94-[FBSWorkspaceScenesClient createWithSceneID:groupID:parameters:transitionContext:completion:]_block_invoke.180
FrontBoardServices  0x7ff819458dc2 -[FBSWorkspace _calloutQueue_executeCalloutFromSource:withBlock:]
FrontBoardServices  0x7ff81948ce5b __94-[FBSWorkspaceScenesClient createWithSceneID:groupID:parameters:transitionContext:completion:]_block_invoke
libdispatch         0x7ff8064a5316 _dispatch_client_callout
libdispatch         0x7ff8064a82d2 _dispatch_block_invoke_direct
FrontBoardServices  0x7ff819458cda __FBSSERIALQUEUE_IS_CALLING_OUT_TO_A_BLOCK__
FrontBoardServices  0x7ff8194a7954 -[FBSSerialQueue _targetQueue_performNextIfPossible]
FrontBoardServices  0x7ff819458ca2 -[FBSSerialQueue _performNextFromRunLoopSource]
CoreFoundation      0x7ff80672315b __CFRUNLOOP_IS_CALLING_OUT_TO_A_SOURCE0_PERFORM_FUNCTION__
CoreFoundation      0x7ff8067230c3 __CFRunLoopDoSource0
CoreFoundation      0x7ff806722e3d __CFRunLoopDoSources0
CoreFoundation      0x7ff806721858 __CFRunLoopRun
CoreFoundation      0x7ff806720e1c CFRunLoopRunSpecific
HIToolbox           0x7ff80f3d05e5 RunCurrentEventLoopInMode
HIToolbox           0x7ff80f3d0349 ReceiveNextEventCommon
HIToolbox           0x7ff80f3d00e4 _BlockUntilNextEventMatchingListInModeWithFilter
AppKit              0x7ff80915af6d _DPSNextEvent
AppKit              0x7ff80915962a -[NSApplication(NSEvent) _nextEventMatchingEventMask:untilDate:inMode:dequeue:]
AppKit              0x7ff80914bcd9 -[NSApplication run]
AppKit              0x7ff80911fc57 NSApplicationMain
AppKit              0x7ff8093f20ee _NSApplicationMainWithInfoDictionary
UIKitMacHelper      0x7ff81c4681fe UINSApplicationMain
UIKitCore           0x7ff914708d0a UIApplicationMain
OurApplication            0x000100e4ef0c main (main.swift:11)

Additional Information

Hello,

Our application uses the Braze SDK on iOS and Mac Catalyst. We use sentry.io to report crashes/hang and it has detected a App Hang when starting the SDK. There are only reports of this happening on macOS, nothing on iOS. It happens on both Intel and M1 machines.

We use the inAppMessagePresenter feature and the SDK initialisation cannot be moved to a background thread to mitigate it on our side.

In the verbose logs is attached the report sent by Sentry.

The SDK is initialised at the start of the application.

Regards,

cbowns commented 1 year ago

Hi @Shakarang, thanks for the report, we'll take a look. A couple of questions: were you able to reproduce this locally, or is this just rolled up from Sentry? (If locally, what percentage of SDK inits hung?)

Shakarang commented 1 year ago

Hey @cbowns, yes I'm able to see the hang locally, it happens during the init. I've attached the screenshot of the Time Profiler.

braze_init
Shakarang commented 1 year ago

Hey! We're getting reports now that it also happens on iOS, both 15 and 16.

cbowns commented 1 year ago

@Shakarang thanks for the trace info and iOS version info.

Broadly, this is an as-designed synchronous call in the SDK: we need it to guarantee data consistency across objects as we write+read to/from flash.

However, the duration you're seeing is longer than we've seen in testing. Do you have any additional information about the distribution of duration across device types + OSes?

(One more thing: this is a pretty quick call stack and a lot shorter than the hangs Sentry usually identifies (iirc, > 2s by default). Do you have their timeout set to something custom?)

Shakarang commented 1 year ago

Thanks for the feedback @cbowns.

Would it be possible to make the initialisation work in another thread instead of relying on the main one?

I don't see any obvious pattern in the device distribution. And for the time, Sentry only reports that the app was stuck for +2s, not more.

No, we didn't set any specific timeout in Sentry.

Also, Sentry reports a lot of other hangs (that have less impacted users though) image

hokstuff commented 1 year ago

Hi @Shakarang,

Would it be possible to make the initialisation work in another thread instead of relying on the main one?

The Swift SDK (and the precursor AppboyKit SDK) require to be initialized on the main thread to ensure expected functionality of the SDK and data consistency, etc. We have not heard of issues from our other clients around the app hanging for 2+ seconds in the past during a vanilla integration, so we'd like to know additional information around your setup.

Can you contact support@braze.com and attach this Github thread with more information around your setup:

Thanks!

lowip commented 1 year ago

Hi @Shakarang, we have just released the SDK 6.2.0 which removes a system call we believe was responsible for the SDK hanging on macOS (iCloud backup exclusion).

I'm closing the issue, feel free to re-open it if the issue persist after upgrading.

Thanks,

Shakarang commented 1 year ago

Hey @lowip,

Thanks for the info and sorry for not following up, I was off for the last weeks. I'll let you know if we still have the issue.

Thanks!