corymsmith / react-native-fabric

A React Native library for Fabric, Crashlytics and Answers
MIT License
1.31k stars 236 forks source link

Need help in Crash log reporting on react native #173

Open GargManish opened 6 years ago

GargManish commented 6 years ago

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
sfreeman28 commented 6 years ago

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

GargManish commented 6 years ago

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.

sfreeman28 commented 6 years ago

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

GargManish commented 6 years ago

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.