[🐛] 🔥 Wrong crash attributes on iOS

[luqas11]

[🐛] 🔥 Wrong crash attributes on iOS

[luqas11]

Hi @mikehardy! Thanks for the quick response.

It appears that your deduction was right. I took the Crashlytics quickstart project, duplicated the crash button, and added the error attributes:

struct CrashButtonView: View {
  var body: some View {
    NavigationView {
        VStack {
            Button(action: {
                let crashlyticsReference = Crashlytics.crashlytics()
                crashlyticsReference.setCustomValue("value1", forKey: "some_attribute")
                crashlyticsReference.setCustomValue("value", forKey: "another_attribute")
                let error = NSError(domain: NSURLErrorDomain, code: -1001, userInfo: nil)
                Crashlytics.crashlytics().record(error: error)
            }) {
                Text("Send Error 1")
            }
            Button(action: {
                let crashlyticsReference = Crashlytics.crashlytics()
                crashlyticsReference.setCustomValue("value2", forKey: "some_attribute")
                let error = NSError(domain: NSURLErrorDomain, code: -1002, userInfo: nil)
                Crashlytics.crashlytics().record(error: error)
            }) {
                Text("Send Error 2")
            }
        }
      .navigationTitle("Crashlytics Example")
    }
  }
}

And, after repeating the experiment, I can see that the bug persists:

For Error 1:

For Error 2:

Both reports have some_attribute set to value2, despite its being set to value1 for the first one. I will open an issue at firebase-ios-sdk and wait for their response.

Thanks again for the analysis!

[luqas11]

Here is the firebase-sdk-ios issue that I created, for future reference: firebase/firebase-ios-sdk#13124

[mikehardy]

Reproductions like you've done are worth more than all the words I can put in a comment box, so your effort is the real motive force here, thanks for pursuing it upstream and hopefully there's a quick resolution - cheers

[mikehardy]

Interesting -

1- javascript implementation is here, does some basic argument validation then defers immediately to native:

react-native-firebase/packages/crashlytics/lib/index.js

Lines 76 to 90 in d849667

	setAttribute(name, value) {
	if (!isString(name)) {
	throw new Error(
	'firebase.crashlytics().setAttribute(*, _): The supplied property name must be a string.',
	);
	}
	if (!isString(value)) {
	throw new Error(
	'firebase.crashlytics().setAttribute(_, *): The supplied property value must be a string value.',
	);
	}
	return this.native.setAttribute(name, value);
	}

2- java implementation similarly does a basic validation that crashlytics is enabled at all, then delegates immediately to firebase-android-sdk:

react-native-firebase/packages/crashlytics/android/src/main/java/io/invertase/firebase/crashlytics/ReactNativeFirebaseCrashlyticsModule.java

Lines 118 to 124 in d849667

	@ReactMethod
	public void setAttribute(String key, String value, Promise promise) {
	if (ReactNativeFirebaseCrashlyticsInitProvider.isCrashlyticsCollectionEnabled()) {
	FirebaseCrashlytics.getInstance().setCustomKey(key, value);
	}
	promise.resolve(null);
	}

3- objective-c also just verifies that crashlytics is enabled then sets the attribute via immediate delegate call to firebase-ios-sdk method:

react-native-firebase/packages/crashlytics/ios/RNFBCrashlytics/RNFBCrashlyticsModule.m

Lines 128 to 137 in d849667

	RCT_EXPORT_METHOD(setAttribute
	: (NSString *)key value
	: (NSString *)value resolver
	: (RCTPromiseResolveBlock)resolve rejecter
	: (RCTPromiseRejectBlock)reject) {
	if ([RNFBCrashlyticsInitProvider isCrashlyticsCollectionEnabled]) {
	[[FIRCrashlytics crashlytics] setCustomValue:value forKey:key];
	}
	resolve([NSNull null]);
	}

By deduction: one of the attributes from report 1 or report 2 would be missing if the argument validation logic or crashlytics enabled verification logic were false, but the attributes are both set (and incorrectly mingled on iOS) so we may infer that we are definitely calling into firebase-ios-sdk with the setAttribute calls

Given there is nothing else happening in this layer of the stack, I think this points to an issue in firebase-ios-sdk

I believe the best next step is to make a similar reproduction using the Crashlytics quickstart https://github.com/firebase/quickstart-ios/tree/main/crashlytics and logging an issue in firebase-ios-sdk repo pointing at the issue there as I think that's where the fault is located

Note especially that if you run the quickstart app under Xcode there is a debugger attached which interferes with Crashlytics: https://github.com/firebase/quickstart-ios/tree/main/crashlytics#trigger-a-crash-in-crashlytics-quickstart-app - this causes a lot of confusion sometimes. You have to launch it manually, not under Xcode

Adding the setAttributes calls (and another crash button) is hopefully a trivial extension to the quickstart so the repro is fast - there is example code included in my code permalinks above

[github-actions]

Hello 👋, to help manage issues we automatically close stale issues.

This issue has been automatically marked as stale because it has not had activity for quite some time.Has this issue been fixed, or does it still require attention?

This issue will be closed in 15 days if no further activity occurs.

Thank you for your contributions.