react-native-fabric icon indicating copy to clipboard operation
react-native-fabric copied to clipboard

Need help in Crash log reporting on react native

Open GargManish opened this issue 7 years ago • 4 comments

We are trying to integrate Crashlytic in our application (on React Native platform). It's providing complete log traces for the native side but we are facing issue in capturing JS originated exceptions. It's capturing JS exception but not providing complete information to find the crash location, file name etc.

We are getting following logs:

Fatal Exception: com.facebook.react.common.JavascriptException: undefined is not an object (evaluating '(void 0).message'), stack:
value@306:637
touchableHandlePress@165:2877
_performSideEffectsForTransition@167:8505
_receiveSignal@167:7292
touchableHandleResponderRelease@167:4757
<unknown>@165:3277
g@41:296
invokeGuardedCallback@41:519
invokeGuardedCallbackAndCatchFirstError@41:634
A@41:2433
D@41:3195
U@41:2992
<unknown>@41:15520
batchedUpdates@41:135761
Ie@41:14871
ze@41:15366
receiveTouches@41:16203
value@18:3582
<unknown>@18:1067
value@18:3009
value@18:1039

       at com.facebook.react.modules.core.ExceptionsManagerModule.showOrThrowError(ExceptionsManagerModule.java:54)
       at com.facebook.react.modules.core.ExceptionsManagerModule.reportFatalException(ExceptionsManagerModule.java:38)
       at java.lang.reflect.Method.invoke(Method.java)
       at com.facebook.react.bridge.JavaMethodWrapper.invoke(JavaMethodWrapper.java:372)
       at com.facebook.react.bridge.JavaModuleWrapper.invoke(JavaModuleWrapper.java:160)
       at com.facebook.react.bridge.queue.NativeRunnable.run(NativeRunnable.java)
       at android.os.Handler.handleCallback(Handler.java:790)
       at android.os.Handler.dispatchMessage(Handler.java:99)
       at com.facebook.react.bridge.queue.MessageQueueThreadHandler.dispatchMessage(MessageQueueThreadHandler.java:29)
       at android.os.Looper.loop(Looper.java:164)
       at com.facebook.react.bridge.queue.MessageQueueThreadImpl$3.run(MessageQueueThreadImpl.java:192)
       at java.lang.Thread.run(Thread.java:764)

So it's not providing information in which class, line number and method this exception has occurred.

I have tried to integrate react-native-fabric and react-native-fabric-crashlytic but still no luck.

There is one more issue in crashlytic, all JS crashes are collating as single type of issues although issues had occurred on different lines.

ExceptionsManagerModule.java line 54#2com.facebook.react.modules.core.ExceptionsManagerModule.showOrThrowError   1.0 (1) 9CRASHES 1USER

GargManish avatar May 29 '18 10:05 GargManish

Hey did you get any further with this? I am experiencing same issue.

I can see in the showOrThrowError method you linked it calls a method JSStackTrace.format(title, details) which contains the following code:

.append(frame.getString("methodName"))
.append("@")
.append(stackFrameToModuleId(frame))
.append(frame.getInt("lineNumber"));

Using that to decode your trace touchableHandlePress@165:2877

touchableHandlePress = methodName 165 = stackFrameToModuleId

I believe 165 is the class name, not very helpful though. I wonder if there is a way to convert this to the actual text class name by using the app source map?

Secondly on the point you made about exceptions being grouped in Fabric even though they were separate JS errors, it seems that when the library sends the exception to Crashlytics in native code it is instantiating a new Exceptions in the same place each time so therefore they get grouped. Has anyone found a way to get around this? How do other bug reporting libraries handle this? It means when ever we mark a bug as fixed in Fabric it will just reopen again when another totally different JS error occurs as its marked as the same native (nonfatal) exception

sfreeman28 avatar Jun 14 '18 00:06 sfreeman28

No Crashlytic isn't supporting it. There are other tools like Sentry, BugSnag which can be used to catch react-native and native crash logs.

GargManish avatar Jun 14 '18 05:06 GargManish

thanks @GargManish. Are you able to tell me if either of those tools support:

  1. separate exception instances in their web console
  2. easier to read stack traces

Thank you

sfreeman28 avatar Jun 17 '18 21:06 sfreeman28

Yes its easy to read stack trace. It provides file name, location etc and also provide separate exception instances as well as it also tracks native crashes.

Try using trial account. There are many available tools Sentry and Bugsnag are two of them. I faced issue with Bugsnag in upload proper source map file which had caused not providing js file name but you can further check.

GargManish avatar Jun 18 '18 05:06 GargManish