Skip to main content

 

Issue Description

We're experiencing signal handler conflicts between Firebase Crashlytics and Intercom SDK in our app. During app initialization, we see multiple warnings in the console:

>Crashlytics] The signal SIGABRT has a non-Crashlytics handler (IntercomSDK_sentrycrashcm_signal_getAPI). This will interfere with reporting.
>Crashlytics] The signal SIGBUS has a non-Crashlytics handler (IntercomSDK_sentrycrashcm_signal_getAPI). This will interfere with reporting.
>Crashlytics] The signal SIGFPE has a non-Crashlytics handler (IntercomSDK_sentrycrashcm_signal_getAPI). This will interfere with reporting.
>Crashlytics] The signal SIGILL has a non-Crashlytics handler (IntercomSDK_sentrycrashcm_signal_getAPI). This will interfere with reporting.
>Crashlytics] The signal SIGSEGV has a non-Crashlytics handler (IntercomSDK_sentrycrashcm_signal_getAPI). This will interfere with reporting.
>Crashlytics] The signal SIGSYS has a non-Crashlytics handler (IntercomSDK_sentrycrashcm_signal_getAPI). This will interfere with reporting.
>Crashlytics] The signal SIGTRAP has a non-Crashlytics handler (IntercomSDK_sentrycrashcm_signal_getAPI). This will interfere with reporting.

This conflict could lead to incomplete or missing crash reports in production.

Feature Request

We need to add configuration options to enable/disable crash reporting services based on the environment or user preferences. This would allow us to:

  1. Choose which crash reporting service to use as primary (Crashlytics or Intercom's Sentry)
  2. Disable specific crash handlers when running in development environments
  3. Comply with user preferences regarding analytics and crash reporting

Technical Notes

  • Both Crashlytics and Intercom's Sentry are installing signal handlers for the same signals (SIGABRT, SIGBUS, SIGFPE, SIGILL, SIGSEGV, SIGSYS, SIGTRAP)
  • The initialization order matters and can affect which handler takes precedence
  • Some SDKs provide configuration options to disable crash reporting (Intercom has enableCrashReporting option)
  • We may need to implement delayed initialization or other techniques to avoid conflicts

Priority

Medium - This issue doesn't crash the app but does impact our ability to receive complete crash reports from users, which affects our ability to fix actual crashes.

Hey ​@Eldhose Lomy Ebenezer here from Engineering Support👋.

Could you write into us with this issue, we’ll need to do some deep debugging to find out the issue is.

This will be easier via the Messenger.

Thanks!


Same for me, would like to know how this will ended up.


I don’t immediately see issues with the intercom iOS crash handler — but i’m here to ask for the same thing.

it is not safe to attach multiple crash handlers to an iOS app at once — signals are re-entrant and there’s no way for two unrelated engineering teams to implement them safely and concurrently 
Since i’m already using another crash handler I”d like to turn it off for intercom.

@Ebenezer.Laleye would you be able to confirm that the guidance found here is still up-to-date?
If i were to follow this would it disable any other class of intercom logs? 


Reply