React-native: Crash on reportSoftException when lineNumber is missing

[arudnev]

🐛 Bug Report

Android app crashes when ExceptionsManagerModule.reportSoftException is called with a stack trace that has frames without lineNumber.

The following fatal exception is logged.

2019-04-09 16:14:29.742 7083-7781/? E/AndroidRuntime: FATAL EXCEPTION: mqt_native_modules
    Process: co.armortext.messenger, PID: 7083
    com.facebook.react.bridge.NoSuchKeyException: lineNumber
        at com.facebook.react.bridge.ReadableNativeMap.getValue(ReadableNativeMap.java:124)
        at com.facebook.react.bridge.ReadableNativeMap.getValue(ReadableNativeMap.java:128)
        at com.facebook.react.bridge.ReadableNativeMap.getInt(ReadableNativeMap.java:182)
        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(Native Method)
        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(Native Method)
        at android.os.Handler.handleCallback(Handler.java:789)
        at android.os.Handler.dispatchMessage(Handler.java:98)
        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$4.run(MessageQueueThreadImpl.java:232)
        at java.lang.Thread.run(Thread.java:764)

When app is running in debug mode something like this can be shown in red box:

To Reproduce

Log exception via console.error with stack that has frames without line numbers.

Expected Behavior

App should not crash and exception stack trace should be formatted without line numbers similar to how it's shown in red box.

Code Example

I don't have a good code sample but it's clear that problem is in the following code, where certain fields are assumed to be always present:

https://github.com/facebook/react-native/blob/97eb53d14fca0197a0d8b0066314b9a148f5f254/ReactAndroid/src/main/java/com/facebook/react/util/JSStackTrace.java#L28

Environment

info
React Native Environment Info:
System:
OS: macOS 10.14.4
CPU: (8) x64 Intel(R) Core(TM) i7-4850HQ CPU @ 2.30GHz
Memory: 1.31 GB / 16.00 GB
Shell: 5.3 - /bin/zsh
Binaries:
Node: 11.13.0 - /usr/local/bin/node
Yarn: 1.15.2 - /usr/local/bin/yarn
npm: 6.7.0 - /usr/local/bin/npm
Watchman: 4.9.0 - /usr/local/bin/watchman
SDKs:
iOS SDK:
Platforms: iOS 12.2, macOS 10.14, tvOS 12.2, watchOS 5.2
Android SDK:
API Levels: 16, 17, 18, 19, 21, 22, 23, 24, 25, 26, 27, 28
Build Tools: 26.0.1, 26.0.2, 27.0.0, 27.0.3, 28.0.0, 28.0.0, 28.0.2, 28.0.3, 29.0.0
System Images: android-21 | Intel x86 Atom, android-21 | Google APIs Intel x86 Atom, android-26 | Google Play Intel x86 Atom, android-27 | Google APIs Intel x86 Atom, android-27 | Google Play Intel x86 Atom, android-28 | Google APIs Intel x86 Atom, android-28 | Google Play Intel x86 Atom
IDEs:
Android Studio: 3.3 AI-182.5107.16.33.5314842
Xcode: 10.2/10E125 - /usr/bin/xcodebuild
npmPackages:
react: 16.8.6 => 16.8.6
react-native: 0.59.4 => 0.59.4

[Salakar]

👋 hey @arudnev - thanks for the report, I've just sent up a PR (#24399) for this.

Would appreciate your review if possible - if the lineNumber does not exist I've set it to -1 instead (which is a common thing to do as far as I remember from when I did Stack Traces stuff a couple weeks back)

[tjann]

I am getting the following error

04-10 22:15:19.664  7325  7353 E AndroidRuntime: FATAL EXCEPTION: mqt_native_modules
04-10 22:15:19.664  7325  7353 E AndroidRuntime: Process: com.myappname, PID: 7325
04-10 22:15:19.664  7325  7353 E AndroidRuntime: com.facebook.react.bridge.NoSuchKeyException: lineNumber
04-10 22:15:19.664  7325  7353 E AndroidRuntime:        at com.facebook.react.bridge.ReadableNativeMap.getValue(ReadableNativeMap.java:124)
04-10 22:15:19.664  7325  7353 E AndroidRuntime:        at com.facebook.react.bridge.ReadableNativeMap.getValue(ReadableNativeMap.java:128)
04-10 22:15:19.664  7325  7353 E AndroidRuntime:        at com.facebook.react.bridge.ReadableNativeMap.getInt(ReadableNativeMap.java:182)
04-10 22:15:19.664  7325  7353 E AndroidRuntime:        at com.facebook.react.util.JSStackTrace.format(JSStackTrace.java:28)
04-10 22:15:19.664  7325  7353 E AndroidRuntime:        at com.facebook.react.modules.core.ExceptionsManagerModule.reportSoftException(ExceptionsManagerModule.java:46)
04-10 22:15:19.664  7325  7353 E AndroidRuntime:        at java.lang.reflect.Method.invoke(Native Method)
04-10 22:15:19.664  7325  7353 E AndroidRuntime:        at com.facebook.react.bridge.JavaMethodWrapper.invoke(JavaMethodWrapper.java:372)
04-10 22:15:19.664  7325  7353 E AndroidRuntime:        at com.facebook.react.bridge.JavaModuleWrapper.invoke(JavaModuleWrapper.java:158)
04-10 22:15:19.664  7325  7353 E AndroidRuntime:        at com.facebook.react.bridge.queue.NativeRunnable.run(Native Method)
04-10 22:15:19.664  7325  7353 E AndroidRuntime:        at android.os.Handler.handleCallback(Handler.java:873)
04-10 22:15:19.664  7325  7353 E AndroidRuntime:        at android.os.Handler.dispatchMessage(Handler.java:99)
04-10 22:15:19.664  7325  7353 E AndroidRuntime:        at com.facebook.react.bridge.queue.MessageQueueThreadHandler.dispatchMessage(MessageQueueThreadHandler.java:29)
04-10 22:15:19.664  7325  7353 E AndroidRuntime:        at android.os.Looper.loop(Looper.java:193)
04-10 22:15:19.664  7325  7353 E AndroidRuntime:        at com.facebook.react.bridge.queue.MessageQueueThreadImpl$4.run(MessageQueueThreadImpl.java:232)
04-10 22:15:19.664  7325  7353 E AndroidRuntime:        at java.lang.Thread.run(Thread.java:764)

This appears to be similar so let me know if providing more information will be helpful.

[karthikpala]

I see that the code is same from 0.52 version of react native. Can anyone please let me know why this issue is coming up in the past week??

[arudnev]

I would expect that in most of older versions the line numbers were generated correctly, but due to some recent issues like https://github.com/facebook/metro/issues/380 there might be some mess with source maps that uncovered need for more defensive code here.

[yogeshchoudhary147]

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.

[helloagain-dev]

We are on react-native 0.56.0 and noticing this issue since a few days now. We will try to cherry pick that commit: https://github.com/Salakar/react-native/commit/ee38bb135fcaa3739f881c29a05c54acef467476 to react-native 0.56.0 and build react native from source.

If anyone has some experience with this, any input would be helpful.

[tjann]

I also tried to build from source and am still trying to recover from that action... I'm inexperienced in react native and mobile in general and there's no documentation to help.

Since installing from source, the strings “path/to/build/directory” consistently fail to get replaced, and firebase is not working.

There's no documentation on undoing install from source either.

Any expert advice will be great!

[pearlismylove]

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

[yogeshchoudhary147]

@helloagain-dev, @tjann and @pearlismylove When exactly have you guys started facing this?

[tjann]

@yogeshchoudhary147

The day after this issue was posted (6 days ago)

[helloagain-dev]

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.

[tonmanayo]

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

[yogeshchoudhary147]

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.

[helloagain-dev]

@yogeshchoudhary147 is it required to build react-native from source after specifying stacktrace-parser version 0.1.4 in package.json?

[yogeshchoudhary147]

@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", ... },

[thangchq-ibl]

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 ?

[yogeshchoudhary147]

@thangchq-ibl If you are using npm, then delete package-lock.json and try

[asvsfs]

i also got this issue only in release builds, happend after upgrading and downgrading react-native

[thangchq-ibl]

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 .

[Calamari]

Heyho.

Can someone confirm that version 0.1.6 of stacktrace-parser fixes this issue as saghul suggests?

And if not, can someone provide a stack trace, that actually produces that lineNumberless item? So I can help out here.

[dwicao]

I believed this is caused by console.error()

[Calamari]

I don't understand this. Usually calling console.error() does not throw an error, so how should it be a cause for an exception screen? And as far as I know, it presents also lineNumbers.
I would be interested to see an actual trace where it chokes, so I can write some tests within stacktrace-parser to safeguard against those.

[stwiname]

@Calamari Im using [email protected] and [email protected] heres an example stack that doesnt get parsed properly:

[email protected]:1:531\[email protected]:1:1469\[email protected]:1:727\[email protected]:1:1505\n102.js:1:2956\[email protected]:1:1247\[email protected]:1:3311\n42.js:1:822\[email protected]:1:2565\[email protected]:1:794\nvalue@[native code]

and the resulting parsed stack

[ { file: '33.js',
    methodName: 's',
    arguments: [],
    lineNumber: 1,
    column: 531 },
  { file: '1959.js',
    methodName: 'b',
    arguments: [],
    lineNumber: 1,
    column: 1469 },
  { file: '2932.js',
    methodName: 'onSocketClose',
    arguments: [],
    lineNumber: 1,
    column: 727 },
  { file: '81.js',
    methodName: 'value',
    arguments: [],
    lineNumber: 1,
    column: 1505 },
  { file: '102.js',
    methodName: '<unknown>',
    arguments: [],
    lineNumber: 1,
    column: 2956 },
  { file: '89.js',
    methodName: 'value',
    arguments: [],
    lineNumber: 1,
    column: 1247 },
  { file: '42.js',
    methodName: 'value',
    arguments: [],
    lineNumber: 1,
    column: 3311 },
  { file: '42.js',
    methodName: '<unknown>',
    arguments: [],
    lineNumber: 1,
    column: 822 },
  { file: '42.js',
    methodName: 'value',
    arguments: [],
    lineNumber: 1,
    column: 2565 },
  { file: '42.js',
    methodName: 'value',
    arguments: [],
    lineNumber: 1,
    column: 794 },
  { file: '[native code]',
    methodName: 'value',
    arguments: [],
    lineNumber: null,
    column: null }
]

[Calamari]

Thanks for the stack @stwiname. I added it to the stacktrace-parser tests, but honestly, I don't see any particular problem here within parsing this. All lines contain all the information that are within the stack string. The last entry does not have any lineNumber or column information, so they are null.

I haven't looked at how react-native is using it, but it is either a problem there or a conceptually one. What happened within stacktrace-parser lately is that a fix is got in showing all the lines that have been dropped silently are now shown in the output, that are lines that don't have a lineNumber.
I think this is the right behavior now. I can also think that we can add a flag into stacktrace-parser that hides "incomplete" lines from the output, but I rather think the better approache is to adapt the usage to cope with null values in lineNumbers as well.

[Calamari]

Btw I also just checked how the android part of react-native is using it, and there are also checks against empty or nulled lineNumbers and columns. So I think everything is fine by now or does anyone have another issue I could look upon?

[Abhishekgarg727]

i got same stack trace, however in my case later i found i forget to import a module i have been using in my code, hence in production version of app , it force stopped whole android app, because in production version developer activity is disabled and it not able to show red screen with error ,as result it making whole app force stopped, its really frustrating especially in my case because the missing imported module i am talking about is only used on certain condition in our app, hence to debug this we need to visit all possible cases, however at last its best to say, always test app whole flow in developer mode before releasing in production. - lesson learned

[GospelHW]

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.

Hi yogeshchoudhary147 May i know how to downgrading it to 0.14 in package.json?

[djangofan]

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

[ianakiara]

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

[SamMatthewsIsACommonName]

We have released a version which includes the fix which was introduced in that release, and yet we are still seeing the error. We also downgraded stacktrace-parser to 0.14. We can't upgrade RN to 0.59.5 on such short notice as we are on 0.55.2 and upgrading will be a lengthy process we need to do slowly and carefully.

Before we do a new release commenting out report soft exception (which would be the 5th release in a week to try and fix this), is there ever scenarios where updates on android don't completely update the underlying binary / code?

[SamMatthewsIsACommonName]

Ok so this is kind of weird. We tracked down the bug and were able to recreate it.
The thing was, on android only it was creating a red box error, which in debug mode triggered our componentDidCatch error handling system. However, in release mode it caused a real crash rather than being caught by the componentDidCatch mechanism. Any ideas why this might be?

[arudnev]

If you review stack trace from the crash report most likely it will become apparent.

I would presume it's due to some conditional logic like this one:

https://github.com/facebook/react-native/blob/bc6dd6b48a51abec0784dce7dc59e51d643d9604/ReactAndroid/src/main/java/com/facebook/react/modules/core/ExceptionsManagerModule.java#L51

[SamMatthewsIsACommonName]

Hi @arudnev thanks I guess what's unusual is it's happening in report soft exception (line 46 of that file) which doesn't seem like it should crash and almost certainly seems like should be caught by componentDidCatch

Fatal Exception: 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.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:160) at com.facebook.react.bridge.queue.NativeRunnable.run(NativeRunnable.java) at android.os.Handler.handleCallback(Handler.java:751) at android.os.Handler.dispatchMessage(Handler.java:95) at com.facebook.react.bridge.queue.MessageQueueThreadHandler.dispatchMessage(MessageQueueThreadHandler.java:29) at android.os.Looper.loop(Looper.java:154) at com.facebook.react.bridge.queue.MessageQueueThreadImpl$3.run(MessageQueueThreadImpl.java:192) at java.lang.Thread.run(Thread.java:761)

[arudnev]

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.

[mojtaba-hajishah]

I'm using React Native 0.55.3.
Downgrading "stacktrace-parser" to "0.1.4" did not fix the issue for me.
Is there any other workaround?

[SamMatthewsIsACommonName]

@arudnev Thanks so much for clarifying, will remove any we can find. No the more info the better thanks!

Edit, we don't use console.error :/ I guess it's probably in a node module somewhere. Thanks

[Crizzooo]

@mojtaba-hajishah Did you ever find a fix?

We are experiencing the same problems with RN 0.57.1, and stacktrace-parser 0.1.4.

[mojtaba-hajishah]

@Crizzooo Unfortunately no.

[Sathyanarayan09]

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

[victorkurauchi]

Any solutions/alternatives for this one ? :( I'm in the same situation of using a live version 0.55.2 and needs to be carefully upgraded...

[SamMatthewsIsACommonName]

@victorkurauchi for us the issue was actually one that should have caused a hard crash, that we found and fixed. It was a bit misleading as it is supposed to be 'report soft exception' however it was just a true typerrror type bug. However it didnt 'catch' in the componentDidCatch mechaism we have, so it was all just a bit weird tbh

[victorkurauchi]

hi @SamMatthewsIsACommonName thanks for the reply. I was reading and looks like some code that triggers console.warn/console.error could lead to this crash ?
So in our code there's no consoles, but ErrorBoundary didCatch might be triggering console.warn/error, so that might be something to investigate...

[victorkurauchi]

an update that our team made without upgrading react-native:

we added "stacktrace-parser": "^0.1.4", into our package.json and released (via Appcenter Codepush). After the release the crashes are now mostly gone.