SIGSEGV - Native Crash running RN 0.70.6 (stacktrace included)

[DevFuan]

Bug Description

• [O] I have run gradle clean and confirmed this bug does not occur with JSC

Hermes version: 0.70.6
React Native version (if any): 0.70.6
OS version (if any): android
Platform (most likely one of arm64-v8a, armeabi-v7a, x86, x86_64): arm64

Working on a blockchain project using an external wallet library
crashes every time an error occurs in Amplify s3 file upload, block chain transaction creation, etc
The Hermes engine settings in the official document were applied.

Does anyone know what could be causing this? I must use the Hermes engine unconditionally
This phenomenon is reproduced in both release and debug modes.
I am holding a project that does not die only in debug, but an error such as [ReferenceError: Property 'err' doesn't exist] is detected
I'm guessing that something is running in Hermes that references the wrong memory address when the error occurs.

code example:

The Expected Behavior

01-12 18:44:51.342 12271 12271 F DEBUG : Revision: '6'
01-12 18:44:51.342 12271 12271 F DEBUG : ABI: 'arm64'
01-12 18:44:51.342 12271 12271 F DEBUG : Processor: '6'
01-12 18:44:51.342 12271 12271 F DEBUG : Timestamp: 2023-01-12 18:44:50.385436524+0900
01-12 18:44:51.342 12271 12271 F DEBUG : Process uptime: 12412s
01-12 18:44:51.342 12271 12271 F DEBUG : signal 11 (SIGSEGV), code 1 (SEGV_MAPERR), fault addr 0x7578c76ff8
01-12 18:44:51.342 12271 12271 F DEBUG : Cause: stack pointer is not in a rw map; likely due to stack overflow.
01-12 18:44:51.342 12271 12271 F DEBUG : x0 0000007578c77300 x1 0000007484000000 x2 0000007578c772f8 x3 0000007578c77068
01-12 18:44:51.342 12271 12271 F DEBUG : x4 0000007578c77060 x5 0000007578c77070 x6 0000000000000000 x7 000000748444ce9c
01-12 18:44:51.342 12271 12271 F DEBUG : x8 ffff00748443d368 x9 0000007578c77308 x10 0000007578c77318 x11 00000076975bf564
01-12 18:44:51.342 12271 12271 F DEBUG : x12 0000000000000033 x13 000000000000006f x14 0000007484afb4e4 x15 0000000000000001
01-12 18:44:51.342 12271 12271 F DEBUG : x16 000000000000000c x17 000000000000008c x18 0000007547d38000 x19 000000001fffffff
01-12 18:44:51.342 12271 12271 F DEBUG : x20 0000007578c77070 x21 0000007578c77068 x22 0000007578c772f8 x23 0000007484000000
01-12 18:44:51.342 12271 12271 F DEBUG : x24 0000007578c77308 x25 0000007697711fd0 x26 0000000000000000 x27 0000007578c772e8
01-12 18:44:51.342 12271 12271 F DEBUG : x28 0000007578c77318 x29 0000007578c77050
01-12 18:44:51.342 12271 12271 F DEBUG : lr 00000076975a5b50 sp 0000007578c76ff0 pc 00000076975a5010 pst 0000000080001000
01-12 18:44:51.342 12271 12271 F DEBUG : backtrace:
#0 ~ #255
01-12 18:44:51.342 12271 12271 F DEBUG : #00 pc 00000000000bb010 /data/app/~~5Yplit4Ax0Eykv2JZVUR7A==/com.testApp-oMb9isTYxxkv9ALccPEzqA==/lib/arm64/libhermes.so (BuildId: 9ba1dafe97991ce4937638cb0269cd51c901346b)

[DevFuan]

I've found a dying point. A memory error occurs when using the eth-json-rpc-errors library(eth_rpc_errors_1.ethErrors.rpc.internal). However, it is difficult to determine whether this is a Hermes issue or an issue with eth-json-rpc-errors

[bbminhtri]

We are having the same issue with eth-json-rpc and eth-json-rpc-errors

[bbminhtri]

Please let us know if you have found any workaround @DevFuan

[DevFuan]

function parseResponse(fetchRes: Response, body: Record<string, Block>): Block {
// check for error code
if (fetchRes.status !== 200) {
throw ethErrors.rpc.internal({
message: Non-200 status code: '${fetchRes.status}',
data: body,
});
}

// check for rpc error
if (body.error) {
throw ethErrors.rpc.internal({
data: body.error,
});
}
// return successful result
return body.result;
}

eth-json-rpc-middleware

Some of the source contents of eth-json-rpc-middleware. Metamasks are currently used in this way, so if you use the same function, you won't get an error.
However, this error-handling library is an older version that does not support, and eth_rpc_errors_1.ethErrors.rpc.internal I don't know why this function is failing to the latest version.

[neildhar]

Thank you for reporting this, are you able to provide a repro or symbolicated stack trace?

[tmikov]

Closing, since no stack trace and no activity