Firebase-ios-sdk: Correct way to force a crash using Objective-C?

[mars-lan]

Step 0: Are you in the right place?

• For issues or feature requests related to __the code in this repository__
  file a Github issue.
  
  
  
  • If this is a __feature request__ please use the Feature Request template.
  
  
• For general technical questions, post a question on StackOverflow
  with the firebase tag.
• For general (non-iOS) Firebase discussion, use the firebase-talk
  google group.
• For backend issues, console issues, and other non-SDK help that does not fall under one
  of the above categories, reach out to
  Firebase Support.
• Once you've read this section and determined that your issue is appropriate for
  this repository, please delete this section.

[REQUIRED] Step 1: Describe your environment

• Xcode version: 11.5
• Firebase SDK version: 6.27.1
• Firebase Component: Crashlytics (Auth, Core, Database, Firestore, Messaging, Storage, etc)
• Component version: 4.2.0
• Installation method: CocoaPods (select one)

[REQUIRED] Step 2: Describe the problem

The doc here suggests that the new way to force crash with Firebase Crashlytics is to use assert(NO) as the legacy [[Crashlytics sharedInstance] crash] has been removed. However, it seems that assert(NO) doesn't actually generate a exception.clsrecord file, which is one of the files the SDK looks for when submitting the crash logs.

Steps to reproduce:

Generate a crash using assert(NO), observe no exception.clsrecord file generated under <crashlytics root>/v5/reports/active/<uuid>

Replacing assert(NO) with @throw NSInternalInconsistencyException; leads to exception.clsrecord generated at the location.

Relevant Code:

See https://firebase.google.com/docs/crashlytics/test-implementation?platform=ios for an example.

[samedson]

It could be based on your project configuration that assert(NO) might not trigger a crash - we might update the docs for this to use a different method. A couple other ways I do it are:

• @[][1]
• int *a = nil; *a = 0;

[mars-lan]

It could be based on your project configuration that assert(NO) might not trigger a crash - we might update the docs for this to use a different method. A couple other ways I do it are:

• @[][1]
• int *a = nil; *a = 0;

Thanks for the quick response. Would be interested to know what project configuration to tweak to enable assert(NO) to crash as that's definitely a cleaner way than any of the suggested alternatives.

[samedson]

I believe it's the existence of the NDEBUG preprocessor macro that will disable assert - looking at https://stackoverflow.com/questions/18339913/does-the-ns-block-assertions-disable-both-nsassert-and-assert-calls?lq=1

[mars-lan]

Actually to be clear the app did crash on assert. It's just not triggering the hooks in firebase SDK to generate the dump needed by crashlytics. See my comments above.

[mapierce]

It could be based on your project configuration that assert(NO) might not trigger a crash - we might update the docs for this to use a different method. A couple other ways I do it are:

• @[][1]
• int *a = nil; *a = 0;

This did the trick for me! assert(NO) wasn't working at all!

[mikemike396]

It could be based on your project configuration that assert(NO) might not trigger a crash - we might update the docs for this to use a different method. A couple other ways I do it are:

• @[][1]
• int *a = nil; *a = 0;

This did the trick for me! assert(NO) wasn't working at all!

This worked for me also! assert(NO) was not reporting in the dashboard!

[samedson]

Alright we've updated the public docs. Change will take a bit to propagate. Thanks for reaching out folks!