Fatal signal 11 (SIGSEGV), code 2 (SEGV_ACCERR) on x86_64

[naqvitalha]

Bug Description

👋
We've been trying Hermes v1 in the Shopify app and we're very happy with the performance improvements! We're however running into random crashes when we run the app inside an emulator in x86_64 environment (basically linux machines where CI checks run). ARM is totally fine.

This is the log we get:

libc    : Fatal signal 11 (SIGSEGV), code 2 (SEGV_ACCERR), fault addr 0x76fcb4f66000 in tid 10790 (le.uiautomation), pid 10790 (le.uiautomation)

The crash's origin is not libhermes however, it only happens with changes made to enable v1. It doesn't happen at a specific point, it's very random and sometimes it doesn't happen at all. I haven't been able to repro it outside the application.

• I have run gradle clean and confirmed this bug does not occur with JSC
• The issue is reproducible with the latest version of React Native.

Hermes git revision (if applicable): 250829098.0.4
React Native version: 0.83.1
OS: Android
Platform (most likely one of arm64-v8a, armeabi-v7a, x86, x86_64): x86_64

Steps To Reproduce

We're still looking into it but decided to raise an issue incase there's a known workaround.

The Expected Behavior

No crashes

[tmikov]

Sorry, there is nothing to go on by. Stack trace at least.

[naqvitalha]

Sorry about that. Here's some additional info that might be useful:

Stacktrace:

SIGSEGV Segmentation violation (invalid memory reference)
/apex/com.android.runtime/lib64/bionic/libc.so:851269 android_unsafe_frame_pointer_chase
/apex/com.android.runtime/lib64/bionic/libc.so:334455 _ZN8gwp_asan18AllocationMetadata12CallSiteInfo15RecordBacktraceEPFmPmmE
/apex/com.android.runtime/lib64/bionic/libc.so:336652 _ZN8gwp_asan20GuardedPoolAllocator10deallocateEPv
/data/app/~~qTbNA4szl_h7l4TacgyuOA==/com.shopify.mobile.uiautomation-ru1IKhtOIZC6kgAW_6fa2A==/base.apk!/lib/x86_64/libhermesvm.so:1202625 0x77918e39a9c1
/data/app/~~qTbNA4szl_h7l4TacgyuOA==/com.shopify.mobile.uiautomation-ru1IKhtOIZC6kgAW_6fa2A==/base.apk!/lib/x86_64/libhermesvm.so:1197089 0x77918e399421
/data/app/~~qTbNA4szl_h7l4TacgyuOA==/com.shopify.mobile.uiautomation-ru1IKhtOIZC6kgAW_6fa2A==/base.apk!/lib/x86_64/libhermesvm.so:1173838 0x77918e39394e
/data/app/~~qTbNA4szl_h7l4TacgyuOA==/com.shopify.mobile.uiautomation-ru1IKhtOIZC6kgAW_6fa2A==/base.apk!/lib/x86_64/libhermesvm.so:1244111 0x77918e3a4bcf
/data/app/~~qTbNA4szl_h7l4TacgyuOA==/com.shopify.mobile.uiautomation-ru1IKhtOIZC6kgAW_6fa2A==/base.apk!/lib/x86_64/libhermesvm.so:1245899 0x77918e3a52cb
/data/app/~~qTbNA4szl_h7l4TacgyuOA==/com.shopify.mobile.uiautomation-ru1IKhtOIZC6kgAW_6fa2A==/base.apk!/lib/x86_64/libhermesvm.so:1167748 0x77918e392184
/data/app/~~qTbNA4szl_h7l4TacgyuOA==/com.shopify.mobile.uiautomation-ru1IKhtOIZC6kgAW_6fa2A==/base.apk!/lib/x86_64/libhermesvm.so:1262609 0x77918e3a9411
/data/app/~~qTbNA4szl_h7l4TacgyuOA==/com.shopify.mobile.uiautomation-ru1IKhtOIZC6kgAW_6fa2A==/base.apk!/lib/x86_64/libhermesvm.so:1167212 0x77918e391f6c
/data/app/~~qTbNA4szl_h7l4TacgyuOA==/com.shopify.mobile.uiautomation-ru1IKhtOIZC6kgAW_6fa2A==/base.apk!/lib/x86_64/libhermesvm.so:2447759 0x77918e4ca98f
/data/app/~~qTbNA4szl_h7l4TacgyuOA==/com.shopify.mobile.uiautomation-ru1IKhtOIZC6kgAW_6fa2A==/base.apk!/lib/x86_64/libhermesvm.so:1628811 0x77918e402a8b
/data/app/~~qTbNA4szl_h7l4TacgyuOA==/com.shopify.mobile.uiautomation-ru1IKhtOIZC6kgAW_6fa2A==/base.apk!libhermesvm.so:713870 hoost_make_fcontext

We also see a warning when the app launches:

W le.uiautomation: Unexpected CPU variant for x86: x86_64.
W le.uiautomation: Known variants: atom, sandybridge, silvermont, goldmont, goldmont-plus, tremont, kabylake, default

Additional device info:

device.cpuAbi: [
"x86_64"
"arm64-v8a"
]
device.manufacturer: "Google"
device.model: "sdk_gphone64_x86_64"
device.osName: "android"
device.osVersion: "14"
device.runtimeVersions.androidApiLevel: "34"
device.runtimeVersions.osBuild: "sdk_gphone64_x86_64-userdebug 14 UE1A.230829.050 12077443 dev-k"

[tmikov]

Interesting. There are some hints here. This could possibly be an incompatibility between Boost.Context and Android's GWP-ASan. The latter tries to record a stack trace and may get confused by the fiber context.

However I also noticed that this stack trace has a different error - SIGSEGV? Also, can you symbolicate it?

[tmikov]

@naqvitalha can you apply #1874 and test?

[naqvitalha]

@tmikov If it's not too much trouble, will it be possible to get a revision that I can swap in the app? We're on 250829098.0.4 right now. Since this only happens on CI, I've been struggling with getting build from source to work there. Let me know!

[tmikov]

Sorry, there is no practical way for me to provide a binary build for you. But I created a branch https://github.com/facebook/hermes/tree/hermes-v250829098.0.4-try-fixcontext with the fix applied on top of v250829098.0.4.

I am not really an expert in building RN projects, but perhaps https://reactnative.dev/contributing/how-to-build-from-source#update-your-project-to-build-from-source can help.