Skip to main content
Question

Conflict Between Crashlytics and Intercom Signal Handlers in iOS

  • March 6, 2025
  • 1 reply
  • 16 views

 

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.

1 reply

Forum|alt.badge.img+4

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!


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