SIGSEGV crash on Android

[rahuljiresal]

This issue seems somewhat related to #6760 , but different enough for a different issue.

The main differences are --

1. The crash happens when there are a lot of components (e.g. 1000 Views nested inside each other). But in the particular instance of our app, the crash also happens when there are relatively fewer components (~100) and we receive a 4xx, 5xx level response from a HTTP call. I have not been able to reproduce this in an isolated project with ~100 components and failed HTTP requests.
2. I am experiencing the crash when I'm NOT connected to Chrome Debugger. It works fine when connected to the debugger.

All I see is this, without a stack trace whatsoever.
A/libc: Fatal signal 11 (SIGSEGV), code 1, fault addr 0xbbadbeef in tid 27250 (mqt_js)

Since the issue happens when I'm not connected to the debugger, it makes it more serious because I cannot distribute the app. Any leads on how to debug this would be helpful.

[fab1an]

See my comment here: software-mansion/react-native-svg#38 (comment)

[rahuljiresal]

So, I created a barebones project to replicate the crash. I put breakpoints at all 3 lines you mentioned in the comment, it didn't stop at any of those before the crash. It stopped at those lines during startup of the app, probably when it was laying out the components.

Here's the dummy app I made, in case you wanted to see if you can reproduce → https://github.com/rahuljiresal/DummyCrashTest

[fab1an]

Seem to be related to: #4172

[rahuljiresal]

Checked that. Not using Google Analytics. Also, the shared libraries are the same for 64 bit and 32 bit architectures. Pretty sure that's not the issue.

[rahuljiresal]

So, after poking around, I found that this line is the culprit → https://github.com/facebook/react-native/blob/master/ReactAndroid/src/main/jni/react/JSCHelpers.cpp#L40

I added log statements before and after the line. It never returns from the function JSEvaluateScript. Crash happens when it is inside that function. The function JSEvaluateScript is not defined anywhere, looks like its a third-party ndk library that gets downloaded(?). Kinda stuck at this point.

[rahuljiresal]

FWIW, also tried disabling JIT like mentioned in this comment #6760 (comment)

Didn't work.

[rahuljiresal]

I found the library that caused the problem for our particular instance. It was the npm dependency we were using called qwest as a wrapper over XHR. I swapped it with another wrapper axios and couldn't reproduce the crash.

There was no invalid JS in qwest, no unexpected exceptions or anything suspicious that I could see. My guess is that the android-jsc simply did not like that JS code and crashed. It seems to be okay with this other wrapper.

I am wondering if it has something to do with the fact that the sources android-JSC is built from is over 20 months old. JavaScriptCore crashing on valid JS is worrisome.

[asata]

"AndroidManifest.xml" add application line

android:hardwareAccelerated="false"

[tomfrew]

We are getting the same issues.

App crashes on Android as soon as an HTTP request returns a 4xx or 5xx response. (In our case triggered by a request to get some analytics settings that doesn't exist so 404s)

When debugging via chrome the issues doesn't happen. We also can't reproduce the crash when the app is built with production flags.

We're tried various suggestions from the related issue threads but so far nothing has worked.

It crashes very reliably for us so if anyone has any debugging suggestions then please let me know!

[AlbertBrand]

We might have found the cause for this crash, see PR #11804. Can you check whether the proposed fix solves this crash?

[shahen94]

I have this issue too, But it works fine when debugging via Chrome

[hramos]

Hi there! This issue is being closed because it has been inactive for a while. Maybe the issue has been fixed in a recent release, or perhaps it is not affecting a lot of people. Either way, we're automatically closing issues after a period of inactivity. Please do not take it personally!

If you think this issue should definitely remain open, please let us know. The following information is helpful when it comes to determining if the issue should be re-opened:

• Does the issue still reproduce on the latest release candidate? Post a comment with the version you tested.
• If so, is there any information missing from the bug report? Post a comment with all the information required by the issue template.
• Is there a pull request that addresses this issue? Post a comment with the PR number so we can follow up.

If you would like to work on a patch to fix the issue, contributions are very welcome! Read through the contribution guide, and feel free to hop into #react-native if you need help planning your contribution.