Answered

help: Significant crashes with iOS SDK relating to [ICMUserIdentity isEqual:]

  • 4 January 2021
  • 6 replies
  • 55 views

I used the intercom widget to post a bug report over 4 weeks ago and my conversation still says it's "not seen yet". Not a good look Intercom.

 

So now I'm going to try posting here and hope that somebody here can graciously be of help.

 

25% of our weekly crashes reported are coming from intercom. And all of it is coming from:

[ICMUserIdentity isEqual:] 

 

Currently version of the app in the store has:

Intercom SDK - 8.0.0

Compiled on XCode 12.1

Support iOS 11.0 and higher.

 

The large majority of our users have migrated to iOS 14 - so its not surprising necessarily that 95% of the crashes are from iOS 14 devices.

 

I have no repro steps unfortunately - just the crash logs showing up in Crashlytics and Apple. It is crashing a non-main thread: com.apple.NSURLSession-delegate

 

Here's a full stack trace:

Crashed: com.apple.NSURLSession-delegate

0 objc_msgSend + 20

1 -[__NSCFString isEqualToString:] + 248

2 -[ICMUserIdentity isEqual:] + 1311236

3 -[ICMIdentityStore isEqual:] + 817664

4 -[ICMIdentityStore saveToDisk] + 817336

5 +[ICMHTTPClient setDeviceTokenSubmitted:] + 761328

6 __106+[ICMHTTPClient updateUserWithUserAttributes:newSession:sentFromBackground:carouselVisible:success:error:]_block_invoke + 738300

7 __62-[ICMOreoEngine operationWithRequest:retries:success:failure:]_block_invoke + 1173916

8 __55-[ICMOreoEngine dataTaskWithRequest:completionHandler:]_block_invoke + 1172652

9 CFNetServiceBrowserSearchForServices + 75852

10 _CFHTTPMessageSetResponseProxyURL + 9332

11 _dispatch_call_block_and_release + 24

12 _dispatch_client_callout + 16

13 _dispatch_lane_serial_drain$VARIANT$armv81 + 568

14 _dispatch_lane_invoke$VARIANT$armv81 + 456

15 _dispatch_workloop_worker_thread + 692

16 _pthread_wqthread + 272

17 start_wqthread + 8

 

Sometimes the stack trace has two calls one after the other to [ICMUserIdentity isEqual:] and sometimes only one - but the net result is that that method is the cause of the crash with an exception of: EXC_BAD_ACCESS KERN_INVALID_ADDRESS

 

hoping for a reply!

icon

Best answer by Eric Fitz 5 January 2021, 16:30

View original

6 replies

Just to further clarify the scope of this crash... we have been running ~98.3% crash free users - of those 1.7% of users who are experiencing a crash, 25% of them are caused by this Intercom issue. So that leads me to believe that we don't have some fundamental implementation problem on our end. This is no doubt an edge case - but one that is still significant enough that it needs looking into regardless as this is still in the neighborhood of 1k users per week.

Userlevel 1

Hey @scott b11​, let me check in with our mobile team about this for you, and I'll come back to you as soon as I have an update!

Userlevel 1

I've checked in with our mobile team and a bug report has been opened. I'll keep you updated here!

Any news on a timeframe for this @eric f11​ ?

Userlevel 1

Hey @scott b11​, I don't have a timeframe to share with you here, our engineers are still investigating this.

OK, thanks @eric f11​  – let me know if there are any more details from my side that would be helpful

Reply