EXC_CRASH during TwilioConversationsClient applicationWillTerminate
kuchmiyalex opened this issue · comments
Just captured this after upgrading to 3.0.0
Any suggestions?
Exception Type: EXC_CRASH (SIGKILL)
Exception Codes: 0x0000000000000000, 0x0000000000000000
Termination Reason: FRONTBOARD 2343432205
<RBSTerminateContext| domain:10 code:0x8BADF00D explanation:[application<com.xxx.live>:17063] failed to terminate gracefully after 5.0s
ProcessVisibility: Unknown
ProcessState: Running
WatchdogEvent: process-exit
WatchdogVisibility: Background
WatchdogCPUStatistics: (
"Elapsed total CPU time (seconds): 7.340 (user 4.880, system 2.460), 21% CPU",
"Elapsed application CPU time (seconds): 0.054, 0% CPU"
) reportType:CrashLog maxTerminationResistance:Interactive>Triggered by Thread: 0
Thread 0 name: Dispatch queue: com.apple.main-thread
Thread 0 Crashed:
0 libsystem_kernel.dylib 0x20dc95da8 __psynch_mutexwait + 8
1 libsystem_pthread.dylib 0x21e3fa150 _pthread_mutex_firstfit_lock_wait + 84
2 libsystem_pthread.dylib 0x21e401310 _pthread_mutex_firstfit_lock_slow + 248
3 libc++.1.dylib 0x1de837b84 std::__1::recursive_mutex::lock() + 16
4 TwilioConversationsClient 0x103cbaea0 rtd::StateMachinertd::TMChannelState::getCurrentState() const + 40
5 TwilioConversationsClient 0x103cafeac rtd::TMChannel::deinitialize(rtd::TErrorInfo const&) + 32
6 TwilioConversationsClient 0x103c7a2e0 rtd::TMChannels::deinitializeChannels() + 340
7 TwilioConversationsClient 0x103c752a8 rtd::TMChannels::deinitialize() + 52
8 TwilioConversationsClient 0x103cd53cc rtd::TMClient::startShutdown() + 224
9 TwilioConversationsClient 0x103cd5248 rtd::TMClient::shutdown() + 144
10 TwilioConversationsClient 0x103e72c14 -[TwilioConversationsClient shutdown] + 612
11 TwilioConversationsClient 0x103e7246c -[TwilioConversationsClient applicationWillTerminate:] + 152
12 CoreFoundation 0x1d01ae3b4 CFNOTIFICATIONCENTER_IS_CALLING_OUT_TO_AN_OBSERVER + 148
13 CoreFoundation 0x1d0255444 ___CFXRegistrationPost_block_invoke + 88
14 CoreFoundation 0x1d02386f4 _CFXRegistrationPost + 440
15 CoreFoundation 0x1d01c29b8 _CFXNotificationPost + 704
16 Foundation 0x1ca53ed0c -[NSNotificationCenter postNotificationName:object:userInfo:] + 92
17 UIKitCore 0x1d308cb7c -[UIApplication _terminateWithStatus:] + 232
18 UIKitCore 0x1d25dc708 -[_UISceneLifecycleMultiplexer _evalTransitionToSettings:fromSettings:forceExit:withTransitionStore:] + 112
19 UIKitCore 0x1d29f3dec -[_UISceneLifecycleMultiplexer forceExitWithTransitionContext:scene:] + 164
20 UIKitCore 0x1d3088f74 -[UIApplication workspaceShouldExit:withTransitionContext:] + 176
21 FrontBoardServices 0x1e5f37e74 __63-[FBSWorkspaceScenesClient willTerminateWithTransitionContext:]_block_invoke_2 + 72
22 FrontBoardServices 0x1e5efcc24 -[FBSWorkspace _calloutQueue_executeCalloutFromSource:withBlock:] + 168
23 FrontBoardServices 0x1e5f37e14 __63-[FBSWorkspaceScenesClient willTerminateWithTransitionContext:]_block_invoke + 128
24 libdispatch.dylib 0x1d7798f88 _dispatch_client_callout + 20
25 libdispatch.dylib 0x1d779ca08 _dispatch_block_invoke_direct + 264
26 FrontBoardServices 0x1e5f06d40 FBSSERIALQUEUE_IS_CALLING_OUT_TO_A_BLOCK + 52
27 FrontBoardServices 0x1e5f068dc -[FBSSerialQueue _targetQueue_performNextIfPossible] + 220
28 FrontBoardServices 0x1e5f09184 -[FBSSerialQueue _performNextFromRunLoopSource] + 28
29 CoreFoundation 0x1d024cf24 CFRUNLOOP_IS_CALLING_OUT_TO_A_SOURCE0_PERFORM_FUNCTION + 28
30 CoreFoundation 0x1d02592fc __CFRunLoopDoSource0 + 176
31 CoreFoundation 0x1d01dd220 __CFRunLoopDoSources0 + 340
32 CoreFoundation 0x1d01f2b7c __CFRunLoopRun + 836
33 CoreFoundation 0x1d01f7eb0 CFRunLoopRunSpecific + 612
34 GraphicsServices 0x20a3ed368 GSEventRunModal + 164
35 UIKitCore 0x1d26ed668 -[UIApplication _run] + 888
36 UIKitCore 0x1d26ed2cc UIApplicationMain + 340
37 XXXXX_APP 0x100913d5c 0x10090c000 + 32092
38 dyld 0x1eeaf0960 start + 2528
@Gray-Wind could you please take a look?
Hi @kuchmiyalex!
If I understand it correctly the Conversations Client were not able to shutdown gracefully in 5 seconds, which led to crash instantiated from the operating system. We will look into the issue, but I need a bit more information. Would you be so kind to open a support ticket and provide some details for your use case such as:
- how many conversations your instance have
- how many participants in conversations
- if it is reproducible locally (on a dev host) it would be great if you attach logs with
debugortracelevel.
Please add a link back to the issue when you open the support ticket.
Hey @kuchmiyalex, any update on the above? Thanks!
@RicardoNunoAlmeida @Gray-Wind thanks, we have rolled back to v2.8.2 due to an unstable chat connection while the app is staying in the background and then returning to the foreground.
As for this crash, I can't reproduce and provide debug/trace logs.
The user had about 400 conversations and every conversation had about 5-10 participants.
Hello @kuchmiyalex,
Can you elaborate on unstable chat connection in background? iOS application in general cannot have any background activity. The SDK must restore the connection once it returns back to foreground.
The provided crash trace indicates that the application itself actually was terminating, this is not a case about restoring from the background. We tried investigate into this issue without any success yet.
Do I understand it correctly, that in fact you are trying to solve the unstable re-connection after your application comes foreground? What is the indication of a bad behaviour of the SDK in this scenario? I am eager to help, but juggling with a lot of unknowns now.
Thanks @Gray-Wind
I think the unstable state is not related to this issue for the crash, we're considering submitting a support ticket with a trace log for you to check.
In general, it looks like the conversation client state is connected, but there are no events coming through, this happens only for one of our testers and is not always reproducible for him.
You might still want to have a look at the trace log, after moving to the foreground at 2023-05-05 14:24:32 there are no callbacks firing until the end of the file, and there are no updates from the conversation client related to new conversations/participants. This user has a lot of activity as could be seen in the log above. After downgrading SDK this is no longer an issue for us.
Thank you for getting back to me with the additional information.
The SDK downloads all available conversations on synchronization and caches them. Subsequent calls are not going to the backend. The local cache updates whenever new conversation appears.
The same happens with the participant list in the each of conversations.
Are there any other indications of connection problems after restoring your application from the background? Are new convesations and/or participants being added after 2023-05-05 14:24:32 during visible 37 seconds of logs?
We will continue with checks on the proper reconnection of the SDK in the meanwhile.
Hello,
We've identified a possible root cause of the reconnection issue. The upcoming release (4.0.0) will include the fix.
Hello,
The release with the fix just been released. Feel free to open a new ticket if you face any issues.