Skip to main content
Answered

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


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!

Best answer by Eric Fitz

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

View original
Did this topic help you find an answer to your question?

6 replies

  • Author
  • New Participant
  • 3 replies
  • January 4, 2021

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.


Eric Fitz
Employee
Forum|alt.badge.img+5
  • Employee
  • 1630 replies
  • January 5, 2021

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!


Eric Fitz
Employee
Forum|alt.badge.img+5
  • Employee
  • 1630 replies
  • Answer
  • January 5, 2021

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


  • Author
  • New Participant
  • 3 replies
  • February 1, 2021

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


Eric Fitz
Employee
Forum|alt.badge.img+5
  • Employee
  • 1630 replies
  • February 1, 2021

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


  • Author
  • New Participant
  • 3 replies
  • February 1, 2021

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


Reply


Cookie policy

We use cookies to enhance and personalize your experience. If you accept you agree to our full cookie policy. Learn more about our cookies.

 
Cookie settings