Crash in `+[TCUtils jsonDictionaryToString:]` starting with version 5.4.18

[defagos]

Hi,

We noticed a new crash in the +[TCUtils jsonDictionaryToString:] method, appearing with Commanders Act SDK version 5.4.18. Such crashes were not happening with version 5.4.17 and now represent a significant amount of the crash reports we receive.

Here is the relevant stack trace:

Exception Type:  EXC_CRASH (SIGABRT)

0   CoreFoundation                	0x18a4a0964  + -1 (:-1)
1   libobjc.A.dylib               	0x1873b5814  + -1 (:-1)
2   Foundation                    	0x1884554c8  + -1 (:-1)
3   TCCore                        	0x102cb6730 +[TCUtils jsonDictionaryToString:] + 44 (TCUtils.m:165)
4   TCCore                        	0x102cafd28 -[TCHTTPOperation addTCUserData:] + 164 (TCHTTPOperation.m:67)
5   TCCore                        	0x102cb3440 -[TCNetworkManager updateQueueWithCategories:] + 192 (TCNetworkManager.m:322)
6   TCCore                        	0x102cb2eb0 -[TCNetworkManager onNotificationReceived:] + 156 (TCNetworkManager.m:225)
7   TCCore                        	0x102cb11a8 -[TCEventListener onNotification:] + 56 (TCEventListener.m:29)
8   CoreFoundation                	0x18a42b860  + -1 (:-1)
9   CoreFoundation                	0x18a42b910  + -1 (:-1)
10  CoreFoundation                	0x18a42b76c  + -1 (:-1)
11  CoreFoundation                	0x18a42bf0c  + -1 (:-1)
12  TCCore                        	0x102cb0c24 -[TCEventSender send:] + 56 (TCEventSender.m:30)
13  TCCore                        	0x102cadda8 -[TCEventManager callOnEnablingTheServerSide] + 88 (TCEventManager.m:78)
14  TCServerSide                  	0x102ce54c4 -[ServerSide initWithSiteID:andSourceKey:notificationCenter:andDefaultBehaviour:andFirebaseInstance:] + 628 (ServerSide.m:179)
15  TCServerSide                  	0x102ce504c -[ServerSide initWithSiteID:andSourceKey:] + 92 (ServerSide.m:115)
16  SRF Sport                     	0x100f92cd0 @nonobjc ServerSide.init(siteID:andSourceKey:) + 24 (CommandersActService.swift:18)
17  SRF Sport                     	0x100f92cd0 ServerSide.__allocating_init(siteID:andSourceKey:) + 24
18  SRF Sport                     	0x100f92cd0 UnprotectedCommandersActService.start(with:) + 144
19  SRF Sport                     	0x100f93788 closure #1 in CommandersActService.start(with:) + 36 (CommandersActService.swift:63)
20  SRF Sport                     	0x100f8639c partial apply for closure #1 in CommandersActService.start(with:) + 16 (Analytics.swift:85)
21  SRF Sport                     	0x100f8639c specialized closure #1 in OSAllocatedUnfairLock.withLockUncheckedInternal<A>(body:) + 16
22  SRF Sport                     	0x100f8639c specialized closure #1 in OSAllocatedUnfairLock.withLockUncheckedInternal<A>(body:) + 16
23  SRF Sport                     	0x100f8639c specialized OSAllocatedUnfairLock.withLockUncheckedInternal<A>(body:) + 16
24  SRF Sport                     	0x100f8639c specialized OSAllocatedUnfairLock.withLock<A>(_:) + 16
25  SRF Sport                     	0x100f8639c CommandersActService.start(with:) + 16
26  SRF Sport                     	0x100f8639c Analytics.start(with:dataSource:delegate:) + 284
27  SRF Sport                     	0x10123f7d4 closure #1 in TrackingService.configure(trackingConfig:) + 132 (TrackingService.swift:33)
28  SRF Sport                     	0x1005f669d <deduplicated_symbol> + 1
29  SRF Sport                     	0x10061acf9 <deduplicated_symbol> + 1
30  SRF Sport                     	0x1005f67f5 <deduplicated_symbol> + 1
31  libswift_Concurrency.dylib    	0x1888ff7b1  + -1 (:-1)

The OS version breakdown shows mostly issues with iOS 26.2+:

Are you aware of changes between versions 5.4.17 and 5.4.18 which could explain the new crash we observe?

Thanks in advance for your help.

Remark

We have opened a GitHub issue on our repository to track the problem on our side as well. Until we know more we have pinned the Commanders Act SDK version to 5.4.17.

[ahakimsaid]

Hello,

Thank you for reporting, it looks like the SDK crashes on initialisation.

No big changes were made between 5.4.17 and 5.4.18, we're evaluating the issue and the options for now. and update this ticket asap !

[defagos]

Thanks for the quick answer. Maybe there is something that was broken with iOS 26.2 but we cannot correlate this hypothesis with the crash reports we receive yet. If we learn more we'll update this issue as well ASAP.

[ahakimsaid]

Could you please share more details about your implementation,
Are you by any chance using your ServerSide instance from multiple threads inside your app ? if so, could you please share the code, it'll be very usefull

Also, are you using the TCConsent module aswell or the TCServerSide only?

Thanks

[defagos]

Of course, our player implementation is entirely public.

To each item we play in our player we can associate one or several trackers. Each tracker implementation receives playback updates via dedicated protocol methods, called on a background serial queue to avoid overloading the main thread.

We have implemented a tracker for Commanders Act tracking and as a result calls to the SDK will be made on background threads, yes. Note that we reported performance problems associated with the use of user defaults by the Commanders Act SDK, see #19, which can lead to delayed display updates when Commanders Act SDK methods are called from the main thread.

Note that we do not use TCConsent at all. We use only TCServerSide and, of course, TCCore.

[ahakimsaid]

Hello!

we were able to identify and patch this bug, a new version has been released https://github.com/CommandersAct/iOSV5/releases/tag/5.4.19

Cheers,

[defagos]

Hi! Thank you very much for the fix. We'll test it and update this issue once we know more.