react-native: Crash on reportSoftException when lineNumber is missing

Hi everyone,

We have figured it out.

It started due a version bump in one of transitive dependencies of react-native i.e. stacktrace-parser. On 5th April, they released 0.1.5 and this crash started happening.

I can confirm that downgrading it to 0.1.4, by specifying it in package.json, has resolved the issue for us.

I’m using react-native 0.59 and experiencing this issue

Hi @SamMatthewsIsACommonName

The error is thrown here when dev support is not enabled and ExceptionsManagerModule is trying to log a stack trace:

https://github.com/facebook/react-native/blob/9a053fc4db1d926824cf579cbfcabcd664618f9b/ReactAndroid/src/main/java/com/facebook/react/modules/core/ExceptionsManagerModule.java#L46

I presume reportSoftException is called when in your JS code you do something like console.error(error). This is just a ReactMethod on a ReactModule, so calls to reportSoftException are processed asynchronously by the bridge, exceptions in that method can not be wrapped and re-thrown back inside of sync calls to console.error, JS keeps going while Java is crashing in parallel 😃 And componentDidCatch would be handling some otherwise unhandled JS exceptions in the component tree, but exception that is happening when you try to log original exception via console.error does not result into yet another JS exception.

So, if in componentDidCatch or in any other code your (or some 3rd-party) library calls console.error it will result into call to reportSoftException, unexpected NoSuchKeyException (only in case of certain weird stack traces) that will not be reported back to JS side and will cause app crash (unless you upgrade to more recent react or downgrade the stack parser, of course).

With dev support enabled the call to console.error would result in red box, but JS code would continue execution and would get to componentDidCatch (or in componentDidCatch it would log exception via console.error, thus causing red box, but no crash). With dev support disabled the call to console.error results into unexpected and unhandled (no control is given back to JS side) NoSuchKeyException in reportSoftException, so JS side does not survive past that console.error call in some exception handling code.

Sorry for somewhat lengthy and redundant explanation.

Thank you @yogeshchoudhary147 I find out way to solve this issue. I use yarn install for my project.so I use "resolutions": { "stacktrace-parser": "0.1.4" } to build this version .

Same crash for us since 5th April. We are on react-native 0.55.4. Don’t know why it started and how to stop it.

I’m having this error on an Android application build , using rn 0.59.3, stacktrace-parser 0.1.6, and node 10.13.0

This fix was released on 0.59.5 https://github.com/facebook/react-native/releases/tag/v0.59.5

Hi @yogeshchoudhary147 I added in my package.son “dependencies”: { …, “react”: “16.3.1”, “react-native”: “0.55.4”, “stacktrace-parser”: “0.1.4”, … } I built debug android work fine but building release Still error :

com.facebook.react.bridge.NoSuchKeyException: lineNumber
                                                       at com.facebook.react.bridge.ReadableNativeMap.getValue(ReadableNativeMap.java:122)
                                                       at com.facebook.react.bridge.ReadableNativeMap.getInt(ReadableNativeMap.java:158)
                                                       at com.facebook.react.util.JSStackTrace.format(JSStackTrace.java:28)
                                                       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(Native Method)
                                                       at com.facebook.react.bridge.JavaMethodWrapper.invoke(JavaMethodWrapper.java:372)
                                                       at com.facebook.react.bridge.JavaModuleWrapper.invoke(JavaModuleWrapper.java:160)```



Do you opinion about this issue ?

Same issue is happening for RN0.59.9 and stacktrace-parser 0.1.6.

I’m having this error on an Android application build , using rn 0.59.3, stacktrace-parser 0.1.6, and node 10.13.0

@helloagain-dev No. This is how my package.json looks like now

"dependencies": { ..., "react": "16.3.1", "react-native": "0.55.4", "stacktrace-parser": "0.1.4", ... },

I am getting the same issue

Fatal Exception: com.facebook.react.bridge.NoSuchKeyException: lineNumber
       at com.facebook.react.bridge.ReadableNativeMap.getValue(ReadableNativeMap.java:120)
       at com.facebook.react.bridge.ReadableNativeMap.getValue(ReadableNativeMap.java:124)
       at com.facebook.react.bridge.ReadableNativeMap.getInt(ReadableNativeMap.java:178)
       at com.facebook.react.util.JSStackTrace.format(JSStackTrace.java:28)
       at com.facebook.react.modules.core.ExceptionsManagerModule.reportSoftException(ExceptionsManagerModule.java:46)
       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:158)
       at com.facebook.react.bridge.queue.NativeRunnable.run(NativeRunnable.java)
       at android.os.Handler.handleCallback(Handler.java:873)
       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:214)
       at com.facebook.react.bridge.queue.MessageQueueThreadImpl$3.run(MessageQueueThreadImpl.java:192)
       at java.lang.Thread.run(Thread.java:764)

RN version 0.58 I think it might be a firebase issue Also this is only happening on android Samsung Galaxy S8, S9, S8+, Huwawe P20 lite and pro

For us it also started pretty much the same time the issue was posted. But only with apps that were re-built since then. This looks a little bit like a transitive dependency that has been updated, although we haven’t figured out which one.