jsc-android-buildscripts: null pointer dereference on jsc-android: 236355.1.1
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
About this issue
- Original URL
- State: open
- Created 5 years ago
- Reactions: 9
- Comments: 43 (10 by maintainers)
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
@matpaul I tried @Kudo changes and worked nicely. I’m still testing doing some performance tests but no more crashes so far. Also I could use minSdkVersion 19 again.
The JSC with changes made by @Kudo is now published on npm with
@nexttag. If you install it withyarn add jsc-android@nextyou should be able to check it. Hopefully soon we will be able to publish as@latest@abdullahsari @rawrmaan @igortupini Hi, can somebody use @Kudo instruction https://gist.github.com/Kudo/cc40662163fbd69dd01d66fd99476c17 and check crashes ?
@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.0And my build wouldn’t succeed until I changed android/build.grade to this:url "$rootDir/../node_modules/@kudo-ci/jsc-android/dist"fromurl "$rootDir/../node_modules/jsc-android/dist"We get both
Fatal signal 11 (SIGSEGV), code 1 (SEGV_MAPERR), fault addr 0x10 in tid 21303 (RenderThread)andFatal 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 https://github.com/wix/react-native-navigation/issues/4651. I presume we’re experiencing the same thing, but tough to know for sure.
@travisgreermoguls you need build jsc yourself or use “@kudo-ci/jsc-android”: “241213.0.0”,
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.thank you @tafty
@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.
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 😦