Hey @Nick  Shauna here from Support!

I’ve gone ahead and opened a conversation with our support team to investigate this for you. They will reach out to you as soon as they can

Giving my +1 here. I’ve also seen this crash today with version 15.0.3 after leaving the app running in the background for a long time and then coming back to it.

I have the same issue – the crashes started after we updated Intercom from 15.0.1 to 15.0.3. I wasn’t able to reproduce it yet, but the stacktrace on Crashlytics is the same as Nick’s. 

Adding my +1 here.

We recently upgraded to 15.0.3 and notice this crash in production.

We were not able to reproduce it but saw this bug growing as more users upgrade to the latest version.

Is there any update? I saw version 15.1.1 is out with

> Fixed an issue where starting a new conversation could cause a crash.

Is this related?

Hi folks

Looking into a fix for this now. Will post when I have an update.

Brian

Hi folks

This has been fixed in release 15.1.2 of the iOS SDK.

Thanks for reporting the issue here.

Brian

@Brian B11 we just started rollout of a version containing that fix (15.1.3) and we’re seeing new crashes that are seemingly related:

SIGSEGV 0x000223111d67d170​​​​​​

Crashed: com.apple.NSURLSession-delegate

0  CoreFoundation                 0xaccec _CFArrayCheckAndGetValueAtIndex + 104

1  CoreFoundation                 0x30240 -o__NSCFArray objectAtIndex:] + 88

2  CoreFoundation                 0x2fd3c CFArrayGetFirstIndexOfValue + 252

3  CoreFoundation                 0x99528 CFRunLoopRemoveTimer + 200

4  CoreFoundation                 0xba6f8 CFRunLoopTimerInvalidate + 576

5  Intercom                       0x5ddcc -tIntercomSDK_IntercomNexusSocket resetConnectionTimeout] + 19880

6  Intercom                       0x5da18 -tIntercomSDK_IntercomNexusSocket handleSocketMessageReceived:] + 18932

7  Intercom                       0x5d88c __61-kIntercomSDK_IntercomNexusSocket listenForWebSocketMessages]_block_invoke + 18536

8  libdispatch.dylib              0x2320 _dispatch_call_block_and_release + 32

9  libdispatch.dylib              0x3eac _dispatch_client_callout + 20

10 libdispatch.dylib              0xb534 _dispatch_lane_serial_drain + 668

11 libdispatch.dylib              0xc0d8 _dispatch_lane_invoke + 436

12 libdispatch.dylib              0x16cdc _dispatch_workloop_worker_thread + 648

13 libsystem_pthread.dylib        0xddc _pthread_wqthread + 288

14 libsystem_pthread.dylib        0xb7c start_wqthread + 8

From a glance, it would seem like you’re invalidating a timer from the callback queue of a URLSession. If that’s the case, you should be able to fix it by making sure the timer is invalidated on the same thread that it is scheduled.

That being said you should probably synchronize all the side-effects that happen as a result of that URLSession callback, unless the things you’re calling are explicitly thread safe.

Hi everyone,
I wanted to chime in and saying that I’m having roughly the same issue as everyone else.

Using 15.1.4 with Firebase, as soon as I “Intercom.loginUser”, CPU usage of the app hits about 130%+ and stays that way until it crashes. Using Instruments I can see a thread with that’s hammering the CPU:

15    __61-�IntercomSDK_IntercomNexusSocket listenForWebSocketMessages]_block_invoke    
11    -�IntercomSDK_IntercomNexusSocket handleSocketMessageReceived:]    
11    -�IntercomSDK_IntercomNexusSocket resetConnectionTimeout]    
6    +iNSTimer(NSTimer) scheduledTimerWithTimeInterval:repeats:block:]    
2    -pNSTimer(NSTimer) initWithFireDate:interval:repeats:block:]    
 

Using a blank SwiftUI app without Firebase works like normal. Not sure if this helps anything but there you go!

I’m seeing similar behavior (extremely high CPU usage) when building with Xcode 15.0 Beta 7 to iOS 17.0 beta 7 on Intercom 15.1.5.

We’re having this issue too on 15.1.4:

https://social-stocks-ld.sentry.io/share/issue/28f10bcf82d14db78e2183574de570b6/

Which version is guaranteed to not have this issue? 15.0.1?

Thank you all 

Yes, 15.0.1 does not have the CPU issue and also includes the fix if you use Lottie.

This issue appears to be resolved when using Intercom 15.2.1!

Reappeared in 15.2.1

https://social-stocks-ld.sentry.io/share/issue/28f10bcf82d14db78e2183574de570b6/

We’re seeing this issue in 16.4.0 on iOS 17.2.1 and can reproduce by doing the following:

1. Log in Intercom user
2. Log out using Intercom.logout()
3. Log in again

The CPU jumps to over 100% right away after the second login.

Additionally, all of our high energy usage reports in Xcode come from the Intercom SDK. There seems to be something wrong with the WebSocket implementation (we use WebSockets elsewhere in our app and do not receive high energy reports from outside of the Intercom SDK).