How do I deobfuscate Crashlytics logs that look like this?

[davidvorona]

We have a react-native app using a few modules in this library. The issue we're having is with Crashlytics: while it catches and reports crashes as expected, for some reason JS exceptions on Android are reported in a format that cannot be deobfuscated by commonly discussed means.

An example of a crash report:

Fatal Exception: com.facebook.react.common.JavascriptException
TypeError: Cannot read property 'id' of undefined This error is located at: in A in o in h in c in A in RCTView in Unknown in y in h in A in Unknown in A in Unknown in Unknown in Unknown in RCTView in Unknown in RCTView in Unknown in b in RCTView in Unknown in n in RCTView in Unknown in RCTView in Unknown in AnimatedComponent(View) in RCTView in Unknown in AnimatedComponent(View) in PanGestureHandler in Unknown in te in Unknown in RCTView in Unknown in Unknown in Unknown in Unknown in V in Unknown in Unknown in Unknown in RCTView in Unknown in RCTView in Unknown in RCTView in Unknown in Unknown in RCTView in Unknown in s in Unknown in PanGestureHandler in Unknown in RCTView in Unknown in s in Unknown in RCTView in Unknown in D in Unknown in RCTView in Unknown in Unknown in RCTView in Unknown in Unknown in H in c in Unknown in RCTView in Unknown in Unknown in S in Unknown in Unknown in Unknown in Unknown in Unknown in RCTView in Unknown in RCTView in Unknown in b in RCTView in Unknown in n in RCTView in Unknown in RCTView in Unknown in AnimatedComponent(View) in RCTView in Unknown in AnimatedComponent(View) in PanGestureHandler in Unknown in te in Unknown in RCTView in Unknown in Unknown in Unknown in Unknown in Unknown in Unknown in Unknown in Unknown in RCTView in Unknown in RCTView in Unknown in RCTView in Unknown in Unknown in RCTView in Unknown in s in Unknown in PanGestureHandler in Unknown in RCTView in Unknown in s in Unknown in RCTView in Unknown in D in Unknown in RCTView i<truncated: 1480 chars>

The link above mentions that this is the "raw" text, and that running the "formatted" text through stack-beautifier with a source map of our code will generate a more readable stack trace. Frankly, I'm not sure what the person answering the SO question is referring to. I see no "formatted" version of this crash log in Crashlytics, and what I've pasted above certainly cannot be deobfuscated.

On the other hand, JS exceptions reported from iOS devices do have a format that can be deobfuscated, and look like this:

Fatal Exception: RCTFatalException: Unhandled JS Exception: RangeError: Out of memory
Unhandled JS Exception: RangeError: Out of memory, stack: E@1717:811 _@1717:716 p@90:497 callTimers@90:2600 value@39:3469 <unknown>@39:662 value@39:2459 value@39:634

Running the above log through stack-beautifier returns a very helpful trace of exactly where the crash happened in our app.

So, what is up with JS exceptions on Android? I'm most confused as to why I don't see more questions about this particularly unhelpful error format online anywhere, it makes me think I'm missing something obvious. I would appreciate some advice on this problem, as we are finding crashes but can do nothing about them since the trace is entirely unhelpful.

[mikehardy]

First thought: hermes or no? The permutations possible on bundling the JS are nearly endless so it's hard to say exactly. The stack traces I got (or used to get - I'm using Hermes now!) were de-obfuscatable but I haven't looked in a while in my own project

[mikehardy]

I do not have more insight sorry - If you're inclined these modules are open

https://github.com/firebase/firebase-android-sdk/tree/master/firebase-crashlytics
https://github.com/firebase/firebase-ios-sdk/tree/master/Crashlytics

...you can put on the caving helmet and go spelunking perhaps. Could be confounded if the truncation happens on the receiving end in the cloud though, I'm not aware of a way to inspect what is happening there

[davidvorona]

I went spelunking.

My experience with native code roughly equates to my experience spelunking, but I get the sense these logs are truncated on the receiving end, in the cloud, and the truncation we're seeing here is meant to handle it more elegantly (even though the developer here admits to the opposite) before the log is written to the file and sent off. Either way, it seems this will be a complex issue to solve.

I will continue to look into this, and will update here if I find anything that could be helpful to others experiencing this.

[mikehardy]

Very interesting. And that's a great log message, glad the dev left that.

can you confirm those really were on one line? no line breaks? That doesn't seem right based on how we're logging these stacks:

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

Lines 175 to 200 in 7117bf4

	private Exception recordJavaScriptError(ReadableMap jsErrorMap) {
	String message = jsErrorMap.getString("message");
	ReadableArray stackFrames = Objects.requireNonNull(jsErrorMap.getArray("frames"));
	boolean isUnhandledPromiseRejection = jsErrorMap.getBoolean("isUnhandledRejection");
	Exception customException;
	if (isUnhandledPromiseRejection) {
	customException = new UnhandledPromiseRejection(message);
	} else {
	customException = new JavaScriptError(message);
	}
	StackTraceElement[] stackTraceElements = new StackTraceElement[stackFrames.size()];
	for (int i = 0; i < stackFrames.size(); i++) {
	ReadableMap stackFrame = Objects.requireNonNull(stackFrames.getMap(i));
	String fn = stackFrame.getString("fn");
	String file = stackFrame.getString("file");
	stackTraceElements[i] = new StackTraceElement("", fn, file, -1);
	}
	customException.setStackTrace(stackTraceElements);
	FirebaseCrashlytics.getInstance().recordException(customException);
	return customException;
	}

They should be formatted line by line and the stack isn't even that big ?
But the result is still truncation somehow. I'm not sure what we're doing wrong to end up with truncation

Tangent questions: What's with all the "Unknown"'s as well? If you enabled Hermes on iOS (it works, I use it) would iOS then also suffer this? You can try it maybe with a test crash button to force both unhandled crashes and native ones (our test app here has those right in the app.js for an example)

[davidvorona]

When I get a chance I will test Hermes on iOS and force some crashes. That would definitely be a helpful exercise.

[mikehardy]

I had the opportunity to ping a Crashlytics Googler at Google I/O for the features required to do an auto-deobfuscation Firebase Extension, for what it's worth. All that's missing is a functions event from crashlytics for crash events to make it technically possible