null pointer dereference on jsc-android: 236355.1.1
rotemmiz opened this issue · 43 comments
Issue Description
JSCore dereferences a null pointer (signal 11 (SIGSEGV), code 1 (SEGV_MAPERR), fault addr 0x0), at some regex calculation (?)
2019-02-07 13:10:27.057 5891-5923/com.reactnativenavigation.playground A/libc: Fatal signal 11 (SIGSEGV), code 1 (SEGV_MAPERR), fault addr 0x0 in tid 5923 (mqt_js), pid 5891 (tion.playground)
2019-02-07 13:10:27.107 1924-1941/? W/libprocessgroup: kill(-3655, 9) failed: No such process
2019-02-07 13:10:27.107 5946-5946/? A/DEBUG: *** *** *** *** *** *** *** *** *** *** *** *** *** *** *** ***
2019-02-07 13:10:27.107 5946-5946/? A/DEBUG: Build fingerprint: 'google/sdk_gphone_x86/generic_x86:9/PSR1.180720.075/5124027:user/release-keys'
2019-02-07 13:10:27.107 5946-5946/? A/DEBUG: Revision: '0'
2019-02-07 13:10:27.107 5946-5946/? A/DEBUG: ABI: 'x86'
2019-02-07 13:10:27.107 5946-5946/? A/DEBUG: pid: 5891, tid: 5923, name: mqt_js >>> com.reactnativenavigation.playground <<<
2019-02-07 13:10:27.107 5946-5946/? A/DEBUG: signal 11 (SIGSEGV), code 1 (SEGV_MAPERR), fault addr 0x0
2019-02-07 13:10:27.107 5946-5946/? A/DEBUG: Cause: null pointer dereference
2019-02-07 13:10:27.107 5946-5946/? A/DEBUG: eax 00000000 ebx cce66ff4 ecx cce6883c edx cc1fc278
2019-02-07 13:10:27.107 5946-5946/? A/DEBUG: edi cc1fc438 esi cce66ff4
2019-02-07 13:10:27.107 5946-5946/? A/DEBUG: ebp cc1fc358 esp cc1fc23c eip 00000000
2019-02-07 13:10:27.145 5946-5946/? A/DEBUG: backtrace:
2019-02-07 13:10:27.145 5946-5946/? A/DEBUG: #00 pc 00000000 <unknown>
2019-02-07 13:10:27.145 5946-5946/? A/DEBUG: #01 pc 006a98a6 /data/app/com.reactnativenavigation.playground-EcLLr4vUusPISFvj2SIIRg==/lib/x86/libjsc.so (JSC::JSObject::toPrimitive(JSC::ExecState*, JSC::PreferredPrimitiveType) const+2550)
2019-02-07 13:10:27.145 5946-5946/? A/DEBUG: #02 pc 0064654b /data/app/com.reactnativenavigation.playground-EcLLr4vUusPISFvj2SIIRg==/lib/x86/libjsc.so (JSC::JSValue::toStringSlowCase(JSC::ExecState*, bool) const+1323)
2019-02-07 13:10:27.145 5946-5946/? A/DEBUG: #03 pc 0075182e /data/app/com.reactnativenavigation.playground-EcLLr4vUusPISFvj2SIIRg==/lib/x86/libjsc.so (JSC::regExpProtoFuncExec(JSC::ExecState*)+222)
2019-02-07 13:10:27.145 5946-5946/? A/DEBUG: #04 pc 000000e0 <anonymous:c9cff000>
Version, config, any additional info
jsc-android: 236355.1.1
react-native: 0.57.7/0.57.8
Issue was reproduced on 32bit version of libjsc, on both arm-v8 devices, x86 and x86_64 android emulators.
Issue is easily reproducible with the following test:
clone https://github.com/wix/react-native-navigation/tree/jscCrashRepro (jscCrashRepro branch)
npm install
cd playground/android
npm run start&
./gradlew installDebug
@DanielZlotin is this the error you encountered when trying to build 64 bit JSCore?
No this looks like something else completely.
Do you know what is the regex reproducing the crash? Or at least what happened in RNN during this.. is this during runtime or while loading/parsing the bundle? a smaller clean project (like in this repo) will maybe help narrow this down.
We run lots of regex tests as part of the benchmark so I doubt it's that, but possible.
Might be just wrong use of API somewhere.
You mentioned 32bit version. Can you try reproduce with x64? (On arm 64)
Also curious to know if this happens with other RN version, and older JSC.
I could also suggest adding logs from those functions to understand what they are, when are they called, and what parameters (null or otherwise) were passed. Log-debugging :(
An important info I forgot to add is that this does not happen on the previous jsc-android release and on stock RN JSCore.
I'll try gathering more data.
Thanks for this comprehensive report @rotemmiz
We've spent some time debugging arm64 crashes last year and I'm glad to see that this one is easily reproducible. Please feel free to mention me next time you make a report. I'll try to look into this one as soon as I have some availability
I'm not sure if the crash I'm experiencing is also related to this issue here. I'm using the latest JSC from here and got a cause: null pointer dereference.
I'm using React-Navigation and not React-Native-Navigation.
- It only happens on Android (works on iOS and react-native-windows)
- Only happens after navigating back and forth x amount of times (clicking on SearchIcon in the header)
- Stops happening when I remove https://github.com/mjsolidarios/react-native-search-filter component from header (which replaces the SearchIcon onPress)
I'll try again with a normal and after this "fix" has been released I'll try again with https://github.com/mjsolidarios/react-native-search-filter
FYI: I just upgraded from RN 0.57.8 to 0.59.0 and removed the jsc injection.
Couldn't reproduce the by me above mentioned crash anymore.
Some update:
-
WebKitGTK has a new major release 2.24.0. Unfortunately did not solve the issue and confirm reproducible.
-
I built a debug build and able to reproduce the crash.
Some context I found:
ForregExpProtoFuncExec, the regex is^#([0-9a-fA-F]{6})$, seems comes from react-native/Libraries/Color/normalizeColor.js.
The target string to do exec(), during call to toPrimitive() (i.e. Symbol.toPrimitive()), there is a null pointer in JSObject::getNonIndexPropertySlot().
Thestructurefrom vm structureIDTable is a null object and structureIDTable is empty table in fact.
From the backtrace, the call path is from JIT code.
I guess there is some race condition during structureIDTable allocate and resize. -
I try to disable DFG_JIT, so far no crash happens.
And yes, as mentioned it needs some patches to fix build error to disable DFG_JIT after WebKitGTK 2.22.
Furthermore, old JSC also turn off DFG_JIT as well.
For my personal available time slot,
I will further to check if release build without DFG_JIT could solve the problem.
And see if disabling DFG_JIT will bring back the 64bit crash issue back or not.
Thankfully to @rotemmiz having an easy reproducible steps for the crash.
Have some more update for 64bit crash issue.
First I could reproduce the crash issue based on @DanielZlotin's work on https://github.com/react-community/jsc-android-buildscripts/tree/RN51x64.
Then I used my custom build JSC (release build WebKitGTK 2.22.6 but disable DFG_JIT).
It seems the DFG_JIT disabled build have no crash issue.
BTW, I cannot test the render deep list test case, there were JNI local reference table overflow from yoga. Other test cases could successfully run in 10 times.
@rotemmiz I've built a JSC without DFG_JIT and seems there are no crash issues from the jscCrashRepro.
Could you please help to further verify that?
Two changes in jscCrashRepro, one for detox 12.0 upgrade as I upgrade Xcode to 10.2 today.
The other and the major one is use my JSC build.
For my JSC build, the changes are at https://github.com/Kudo/jsc-android-buildscripts/commits/develop and built by CircleCI as well.
I will create PRs if the DFG_JIT disabled build passed you testing.
On a project I am working on we experienced a similar issue whilst running a release build to Samsung S6s (see log below).
@Kudo I have just tested using a fork of react-native-navigation that used your JSC build and it has fixed our issue. Thanks!
2019-04-03 14:37:56.569 18149-18149/? A/DEBUG: *** *** *** *** *** *** *** *** *** *** *** *** *** *** *** ***
2019-04-03 14:37:56.570 18149-18149/? A/DEBUG: Build fingerprint: 'samsung/zerofltexx/zeroflte:7.0/NRD90M/G920FXXU6ERF5:user/release-keys'
2019-04-03 14:37:56.570 18149-18149/? A/DEBUG: Revision: '11'
2019-04-03 14:37:56.570 18149-18149/? A/DEBUG: ABI: 'arm'
2019-04-03 14:37:56.570 18149-18149/? A/DEBUG: pid: 18066, tid: 18119, name: mqt_js >>> com.my.package.systest <<<
2019-04-03 14:37:56.570 18149-18149/? A/DEBUG: signal 11 (SIGSEGV), code 1 (SEGV_MAPERR), fault addr 0xbbadbeef
2019-04-03 14:37:56.570 18149-18149/? A/DEBUG: r0 c517c40c r1 fffffffe r2 bbadbeef r3 00000000
2019-04-03 14:37:56.570 18149-18149/? A/DEBUG: r4 c37c7cb0 r5 10a592f4 r6 f5238e78 r7 00000014
2019-04-03 14:37:56.570 18149-18149/? A/DEBUG: r8 376cb440 r9 c37c7cb0 sl 00000000 fp c517c520
2019-04-03 14:37:56.570 18149-18149/? A/DEBUG: ip c9a0ce24 sp c517c490 lr c99bcd67 pc c99bcd9c cpsr 400e0030
2019-04-03 14:37:56.571 18149-18149/? A/DEBUG: backtrace:
2019-04-03 14:37:56.575 18149-18149/? A/DEBUG: #00 pc 00142d9c /data/app/com.my.package.systest-1/lib/arm/libjsc.so (offset 0x40000)
2019-04-03 14:37:56.575 18149-18149/? A/DEBUG: #01 pc 00142d63 /data/app/com.my.package.systest-1/lib/arm/libjsc.so (offset 0x40000)```
@tafty can you explain how to fix it . Im' really newbie. So how to use JSC for android . I have a big problem when I sometimes push screen (react-native-navigation v2) and react native: 0.59.3 , my app is crash and just throw err Fatal signal 11 (SIGSEGV), code 1, fault addr 0x0 in tid 27604 (mqt_js), pid 27575. Please help me. Thank you so much.
@huuthinh245 I forked react-native-navigation and created a branch from the release that we are currently using in our project (2.11.0) then updated package.json to use Kudo's repository containing the JSC fix. You can see that commit here:
https://github.com/UnomeeLtd/react-native-navigation/commit/d2fdb886ccb1f632db8fdb8bb8f7641e3144de62
There is also a second commit on that branch to upgrade Detox to allow it to work with the latest XCode. I then altered pacakge.json in our project to reference my fork:
"react-native-navigation": "git+https://git@github.com/UnomeeLtd/react-native-navigation.git#jsc-android-fix-test",
This allowed me to prove that the fix would work. However, I should also add that in our project I was able to revert the change that resulted in hitting the fatal error and am waiting until Kudo's change is merged into the main jsc-android-buildscripts repository and picked up by react-native-navigation before re-instating that change. You may be less cautious than I am or perhaps are unable to wait...
thank you @tafty
@bruchim I am sorry not sent a PR for disabled DFG_JIT yet.
I will have some measurement for the impact of disabling DFT_JIT.
Unfortunately suggested fix doesn't work for me. Crash happens after upgrading to RN 0.59.4. Android build crashes after several push/pop operations
I attempted using the forks as well but no luck with RN 0.59.4 either
We use @Kudo develop branch, after deploy some users can enter the app but then fatal with very strange errors in js on some devices (samsung s7 android 7) facebook/react-native#24261
We try downgrade jsc to 225067 (on RN < 0.59 we have no issues) - no success on RN 0.59
I think downgrade jsc + 32 bit build only will help but it's not good fix =(
RN 0.59's model to adopt jsc-android might not reliable. (assuming to use packageOptions.pickFirst for libjsc.so)
Please execute the command adb logcat | grep 'JavaScriptCore.Version' to double check the JSC version is expected.
My JSC version should be "241213.0.0"
RN 0.59 stock JSC is "236355.1.0"
We know that there are a lot of JSC crash feedbacks. Unfortunately, these crash issues may related to JIT and not easy to reproduce in-house.
We are trying to improve the experience to upgrade JSC in RN 0.60.
In upcoming RN 0.60, hopefully simply yarn add jsc-android@{version} is the only command needed to upgrade JSC.
With this new model, hopefully we could provide early experimented solution for user to test.
This is likely a very simple question, however I can't seem to answer it.
We have a similar crashing issue (though it appears to affect Android 9 much more) with RNN. I'm attempting to use @Kudo's develop branch. After updating my package.json to use it ("jsc-android": "git+https://github.com/Kudo/jsc-android-buildscripts.git#develop"), running yarn install, then react-native run-android - the build fails with:
> Could not find org.webkit:android-jsc:r241213.
Does the jsc-android package (from develop branch) need to be specifically built first? (I've been unsuccessfully working on that, but will persist) Is there something else I'm missing to test the develop branch change?
We were initially on 0.58.6 & RNN v1. I was able to test that both JSC 236355.1.1 & 241213.0.0 did not fix the problem (for arm, could not get JSC working on 0.58 w/arm64). We upgraded to 0.59.0 and RNN v2 (2.18.0) and continue to get the problem - which we expected based on this thread. I'd love to figure out how to test @Kudo's DFG_JIT change to see if it will address our crashes.
@travisgreermoguls you need build jsc yourself or use "@kudo-ci/jsc-android": "241213.0.0",
@matpaul this is exactly what I was looking for, thank you!
Unfortunately, our app still crashes - even with @Kudo's change.
I feel confident I'm actually using the disabled DFG_JIT code. This is the reported JSC version:
05-03 08:26:44.858 28337 28553 D JavaScriptCore.Version: 241213.0.0
And my build wouldn't succeed until I changed android/build.grade to this:
url "$rootDir/../node_modules/@kudo-ci/jsc-android/dist"
from
url "$rootDir/../node_modules/jsc-android/dist"
We get both
Fatal signal 11 (SIGSEGV), code 1 (SEGV_MAPERR), fault addr 0x10 in tid 21303 (RenderThread)
and
Fatal signal 6 (SIGABRT), code -6 (SI_TKILL) in tid 28557 (HybridData Dest)
I'd be happy to do whatever to help debug as we still need to resolve our crash, regardless. I arrived on this thread from wix/react-native-navigation#4651. I presume we're experiencing the same thing, but tough to know for sure.
@travisgreermoguls you can try temporary workaround - build only 32 bit
ndk {
abiFilters "armeabi-v7a", "x86", "arm64-v8a", "x86_64" -> change to
abiFilters "armeabi-v7a", "x86"
}
be notice that google play store do not support 32 bit apps after 1 August 2019
@matpaul Thanks for the suggestion, I appreciate the help. I tried it and it still fails. Not sure what that means, maybe our app is encountering something different? If so, I'm not sure what.
In case it helps, here's the beginning of the logcat:
05-03 10:12:48.547 6025 6035 F libc : Fatal signal 11 (SIGSEGV), code 1 (SEGV_MAPERR), fault addr 0x2922 in tid 6035 (FinalizerDaemon), pid 6025 (ts.football2017)
05-03 10:12:48.761 6986 6986 I crash_dump32: obtaining output fd from tombstoned, type: kDebuggerdTombstone
05-03 10:12:48.767 934 934 I /system/bin/tombstoned: received crash request for pid 6035
05-03 10:12:48.771 6986 6986 I crash_dump32: performing dump of process 6025 (target tid = 6035)
05-03 10:12:48.788 6986 6986 F DEBUG : *** *** *** *** *** *** *** *** *** *** *** *** *** *** *** ***
05-03 10:12:48.789 6986 6986 F DEBUG : Build fingerprint: 'google/walleye/walleye:9/PQ2A.190405.003/5310204:user/release-keys'
05-03 10:12:48.789 6986 6986 F DEBUG : Revision: 'MP1'
05-03 10:12:48.789 6986 6986 F DEBUG : ABI: 'arm'
05-03 10:12:48.789 6986 6986 F DEBUG : pid: 6025, tid: 6035, name: FinalizerDaemon >>> com.atomic.cbssports.football2017 <<<
05-03 10:12:48.789 6986 6986 F DEBUG : signal 11 (SIGSEGV), code 1 (SEGV_MAPERR), fault addr 0x2922
05-03 10:12:48.789 6986 6986 F DEBUG : r0 9ccf6820 r1 00002922 r2 00000008 r3 40000000
05-03 10:12:48.789 6986 6986 F DEBUG : r4 bc46f680 r5 00000000 r6 00000000 r7 d37c9ad0
05-03 10:12:48.789 6986 6986 F DEBUG : r8 00000000 r9 eb4ba000 r10 00000000 r11 d37c985c
05-03 10:12:48.789 6986 6986 F DEBUG : ip ee6e8d00 sp d37c97d8 lr ee6c136b pc ee447664
05-03 10:12:48.881 6986 6986 F DEBUG :
05-03 10:12:48.881 6986 6986 F DEBUG : backtrace:
05-03 10:12:48.881 6986 6986 F DEBUG : #00 pc 00054664 /system/lib/libcrypto.so (EVP_MD_CTX_free+18)
05-03 10:12:48.881 6986 6986 F DEBUG : #01 pc 000132df /system/framework/arm/boot-conscrypt.oat (offset 0x13000) (com.android.org.conscrypt.NativeCrypto.BIO_free_all [DEDUPED]+102)
05-03 10:12:48.881 6986 6986 F DEBUG : #02 pc 0040d575 /system/lib/libart.so (art_quick_invoke_stub_internal+68)
This is an earlier logcat, don't recall the exact params, I think it was using a released JSC, 0.59 and arm64. But it reported an actual cause: "null pointer dereference" vs the above which only references "fault addr 0x2922". Though I really don't know the significance (if any) of these.
05-02 09:59:15.650 21693 21693 F DEBUG : Build fingerprint: 'google/walleye/walleye:9/PQ2A.190405.003/5310204:user/release-keys'
05-02 09:59:15.650 21693 21693 F DEBUG : Revision: 'MP1'
05-02 09:59:15.650 21693 21693 F DEBUG : ABI: 'arm64'
05-02 09:59:15.650 21693 21693 F DEBUG : pid: 21222, tid: 21303, name: RenderThread >>> com.atomic.cbssports.football2017 <<<
05-02 09:59:15.650 21693 21693 F DEBUG : signal 11 (SIGSEGV), code 1 (SEGV_MAPERR), fault addr 0x10
05-02 09:59:15.650 21693 21693 F DEBUG : Cause: null pointer dereference
@travisgreermoguls we have same error(Fatal signal 11 (SIGSEGV), code 1 (SEGV_MAPERR)) before x64 (use react-native-navigation),
when we downgrade jsc to "225067" everything work - you can try => 32bit only + jsc version "225067"
I don't have device to reproduce it (
@matpaul That setup (JSC 225067, 0.59.0, 32-bit, Android 9) still fails for our app. In case some context helps, we have noticed our problem appears to affect our Android 9 users significantly more (Impacted sessions 54% for 9, vs 4.6% for 8.1 and older, via Play Console). I haven't been able to find any other reports of problems with specifically on Android 9.
Oddly, when testing JSC 225067, in three tests I got Fatal signal 11 first and third and a signal 4 on the second test. I've seen signal 6 in testing, but never signal 4 - though all my test are manual, so low numbers.
Anyhow, I do still appreciate the advice @matpaul . Happy to keep trying just about anything.
@travisgreermoguls Thanks for info
@travisgreermoguls It seems your backtrace not related to JSC. Could your please double check that?
Since there are various crash types, it would be help to troubleshoot if you could provide JSC backtrace.
Thanks.
@Kudo I'm not experienced at interpreting the backtrace, so I defer to your take. I just reproduced the bug on my device and here is the backtrace. How do you tell if it's related to the JSC? And let me know if I'm not including enough info or accurately pulling the backtrace.
After getting all the help and advice from matpaul (thanks!!), and none of the 'fixes' addressing our crash issue, it would make sense that we are dealing with something different. This was the closest match to our issue, so I pursued it first.
05-07 09:34:39.247 18979 18979 F libc : Fatal signal 11 (SIGSEGV), code 2 (SEGV_ACCERR), fault addr 0x7a1dba5040 in tid 18979 (ts.football2017), pid 18979 (ts.football2017)
05-07 09:34:39.432 19923 19923 I crash_dump64: obtaining output fd from tombstoned, type: kDebuggerdTombstone
05-07 09:34:39.439 934 934 I /system/bin/tombstoned: received crash request for pid 18979
05-07 09:34:39.442 19923 19923 I crash_dump64: performing dump of process 18979 (target tid = 18979)
05-07 09:34:39.452 19923 19923 F DEBUG : *** *** *** *** *** *** *** *** *** *** *** *** *** *** *** ***
05-07 09:34:39.452 19923 19923 F DEBUG : Build fingerprint: 'google/walleye/walleye:9/PQ2A.190405.003/5310204:user/release-keys'
05-07 09:34:39.452 19923 19923 F DEBUG : Revision: 'MP1'
05-07 09:34:39.452 19923 19923 F DEBUG : ABI: 'arm64'
05-07 09:34:39.452 19923 19923 F DEBUG : pid: 18979, tid: 18979, name: ts.football2017 >>> com.atomic.cbssports.football2017 <<<
05-07 09:34:39.452 19923 19923 F DEBUG : signal 11 (SIGSEGV), code 2 (SEGV_ACCERR), fault addr 0x7a1dba5040
05-07 09:34:39.452 19923 19923 F DEBUG : x0 00000079626c46a0 x1 000000797ada2ad0 x2 0000007fef6356c0 x3 0000000000000000
05-07 09:34:39.452 19923 19923 F DEBUG : x4 0000000000000000 x5 0000000000000000 x6 0000000000000000 x7 00ffffffffffffff
05-07 09:34:39.452 19923 19923 F DEBUG : x8 0000007a1dba5040 x9 ff09acaea8a5be77 x10 0000000000000001 x11 0000000000000000
05-07 09:34:39.452 19923 19923 F DEBUG : x12 0000000000000008 x13 ffffffffffffffff x14 ffffffffffffff00 x15 ffffffffffffffff
05-07 09:34:39.452 19923 19923 F DEBUG : x16 0000007a1dbc6f08 x17 0000007a1d8dcf90 x18 0000007fef634e2a x19 000000796278d3c0
05-07 09:34:39.452 19923 19923 F DEBUG : x20 000000796278d3e8 x21 00000000144bcf90 x22 00000000144bcf90 x23 00000000137d1f58
05-07 09:34:39.452 19923 19923 F DEBUG : x24 00000000144bcf90 x25 0000000000000000 x26 000000009d78cab0 x27 0000000000000000
05-07 09:34:39.452 19923 19923 F DEBUG : x28 0000000000000001 x29 0000007fef635740
05-07 09:34:39.452 19923 19923 F DEBUG : sp 0000007fef635720 lr 0000007a1d8dcfe4 pc 0000007a1dba5040
05-07 09:34:39.627 19923 19923 F DEBUG :
05-07 09:34:39.627 19923 19923 F DEBUG : backtrace:
05-07 09:34:39.627 19923 19923 F DEBUG : #00 pc 000000000076c040 /system/lib64/libhwui.so (offset 0x6f7000)
05-07 09:34:39.627 19923 19923 F DEBUG : #01 pc 00000000004b2fe0 /system/lib64/libhwui.so (SkPixelRef::callGenIDChangeListeners()+80)
05-07 09:34:39.627 19923 19923 F DEBUG : #02 pc 00000000004b2f58 /system/lib64/libhwui.so (SkPixelRef::~SkPixelRef()+32)
05-07 09:34:39.627 19923 19923 F DEBUG : #03 pc 000000000047be08 /system/lib64/libhwui.so (android::Bitmap::~Bitmap()+16)
05-07 09:34:39.627 19923 19923 F DEBUG : #04 pc 000000000013aaac /system/lib64/libandroid_runtime.so (Bitmap_recycle(_JNIEnv*, _jobject*, long)+12)
05-07 09:34:39.627 19923 19923 F DEBUG : #05 pc 00000000003cf518 /system/framework/arm64/boot-framework.oat (offset 0x3cd000) (android.content.res.ApkAssets.nativeIsUpToDate [DEDUPED]+152)
05-07 09:34:39.627 19923 19923 F DEBUG : #06 pc 000000000090cccc /system/framework/arm64/boot-framework.oat (offset 0x3cd000) (android.graphics.Bitmap.recycle+60)
05-07 09:34:39.627 19923 19923 F DEBUG : #07 pc 00000000001a9fd0 /data/app/com.atomic.cbssports.football2017-MrQEm63RsYZlO4exOCZPMA==/oat/arm64/base.odex (offset 0x193000) (com.facebook.imagepipeline.memory.BitmapPool.free+144)
05-07 09:34:39.627 19923 19923 F DEBUG : #08 pc 000000000033c98c /data/app/com.atomic.cbssports.football2017-MrQEm63RsYZlO4exOCZPMA==/oat/arm64/base.odex (offset 0x193000) (com.facebook.imagepipeline.memory.BasePool.release+2556)
05-07 09:34:39.627 19923 19923 F DEBUG : #09 pc 000000000020f59c /data/app/com.atomic.cbssports.football2017-MrQEm63RsYZlO4exOCZPMA==/oat/arm64/base.odex (offset 0x193000) (com.facebook.common.references.SharedReference.deleteReference+172)
05-07 09:34:39.627 19923 19923 F DEBUG : #10 pc 000000000020e618 /data/app/com.atomic.cbssports.football2017-MrQEm63RsYZlO4exOCZPMA==/oat/arm64/base.odex (offset 0x193000) (com.facebook.common.references.CloseableReference.close+104)
05-07 09:34:39.627 19923 19923 F DEBUG : #11 pc 00000000001a9e18 /data/app/com.atomic.cbssports.football2017-MrQEm63RsYZlO4exOCZPMA==/oat/arm64/base.odex (offset 0x193000) (com.facebook.imagepipeline.image.CloseableStaticBitmap.close+72)
05-07 09:34:39.627 19923 19923 F DEBUG : #12 pc 000000000020c51c /data/app/com.atomic.cbssports.football2017-MrQEm63RsYZlO4exOCZPMA==/oat/arm64/base.odex (offset 0x193000) (com.facebook.common.internal.Closeables.close+92)
05-07 09:34:39.627 19923 19923 F DEBUG : #13 pc 00000000001a1268 /data/app/com.atomic.cbssports.football2017-MrQEm63RsYZlO4exOCZPMA==/oat/arm64/base.odex (offset 0x193000) (com.facebook.common.references.CloseableReference$1.release+56)
05-07 09:34:39.627 19923 19923 F DEBUG : #14 pc 0000000000005c7c /dev/ashmem/dalvik-jit-code-cache (deleted)
05-07 09:34:40.734 934 934 E /system/bin/tombstoned: Tombstone written to: /data/tombstones/tombstone_02
@travisgreermoguls If the crash related to JSC, in the backtrace you should see libjsc.so.
For example, from #84 (comment):
2019-02-07 13:10:27.145 5946-5946/? A/DEBUG: #00 pc 00000000 <unknown>
2019-02-07 13:10:27.145 5946-5946/? A/DEBUG: #01 pc 006a98a6 /data/app/com.reactnativenavigation.playground-EcLLr4vUusPISFvj2SIIRg==/lib/x86/libjsc.so (JSC::JSObject::toPrimitive(JSC::ExecState*, JSC::PreferredPrimitiveType) const+2550)
2019-02-07 13:10:27.145 5946-5946/? A/DEBUG: #02 pc 0064654b /data/app/com.reactnativenavigation.playground-EcLLr4vUusPISFvj2SIIRg==/lib/x86/libjsc.so (JSC::JSValue::toStringSlowCase(JSC::ExecState*, bool) const+1323)
2019-02-07 13:10:27.145 5946-5946/? A/DEBUG: #03 pc 0075182e /data/app/com.reactnativenavigation.playground-EcLLr4vUusPISFvj2SIIRg==/lib/x86/libjsc.so (JSC::regExpProtoFuncExec(JSC::ExecState*)+222)
2019-02-07 13:10:27.145 5946-5946/? A/DEBUG: #04 pc 000000e0 <anonymous:c9cff000>
@Kudo Thank you for the clarification!
Downgrading JSC to r225067 seems to have resolved this issue for me.
I can also confirm that downgrading JSC to r225067 fixed all my no-stack-trace SEGV_MAPERR crashes.
Downgrading to r225067 fixed all my crashed too, but I had to set my minimum SDK Version to 21.
@abdullahsari @rawrmaan @igortupini Hi, can somebody use @Kudo instruction https://gist.github.com/Kudo/cc40662163fbd69dd01d66fd99476c17 and check crashes ?
@Kudo first of all, thanks for the PR!
Anyway, I just saw a new version of WebKitGTK has been released a few days ago (with some crashes fix):
https://webkitgtk.org/2019/05/17/webkitgtk2.24.2-released.html
(It's a patch version, not sure if it solves our crash but it worth a try.)
I'm trying to build JSC with this new version (2.24.2) but it does not seem to easy since few of the patches are not relevant and need a fix.
I'll keep you posted..
@bruchim Yes, there are many changes from upstream and will have many breaks.
I've tried 2.24.0 before.
From my previous experience, the major broken change is that JIT is not support for x86.
Since WebKit upstream changed their JIT LLInt bytecode format, and 32bit platforms were not supported.
ARM 32 support was contributed by igalia
This worked for our app as well (downgrading to r225067) - SEGV_MAPPER crashes dropped, along with some additional JavaScript exceptions where variable values were clearly incorrect (these only appeared when we deployed our app at scale with r236355 and they could not be easily reproduced).
The JSC with changes made by @Kudo is now published on npm with @next tag. If you install it with yarn add jsc-android@next you should be able to check it. Hopefully soon we will be able to publish as @latest
React native 0.59.10 bumped the JSC version to 245459.0.0 . This includes the fixes from @Kudo .
Fixed the problem for me.
React native 0.59.10 bumped the JSC version to 245459.0.0 . This includes the fixes from @Kudo .
Fixed the problem for me.
I think on 0.59.9 was already fixed.
For those who are big suffered by this problem!
I've tried all of the above remedies, but none of them work in RN 0.69 and React Navigation 6.
So I've used "transitionEnd" event of React Navigation, I've solved this.
Below is my worked code.
// React component class file
constructor(props) {
super(props)
this.state = {
isWebViewLoaded: false,
}
props.navigation.addListener('transitionEnd', () => {
this.setState({ isWebViewLoaded: true })
})
props.navigation.addListener('beforeRemove', () => {
this.setState({ isWebViewLoaded: false })
})
}
render() {
return (
<View style={{ flex: 1, position: 'relative' }}>
{this.state.isWebViewLoaded && (
<WebView
source={{
uri: 'https://google.com/',
headers: { 'Cache-Control': 'no-cache' },
}}
renderError={() => {
return (
<View
style={{
flex: 1,
alignItems: 'center',
justifyContent: 'center',
}}
Network connection error.
)
}}
/>
)}
)
// package.json file
"@react-navigation/native": "^6.0.11",
"@react-navigation/native-stack": "^6.7.0",
"@react-navigation/stack": "^6.2.2",
"react": "18.2.0",
"react-native": "0.69.1",
"react-native-gesture-handler": "^2.5.0",
"react-native-screens": "^3.15.0",
"react-native-webview": "^11.22.7"