JVM SIGSEGV in native bcos_sdk_stop when stopping/destroying SDK or EventSubscribe

[kyonRay]

Description

Calling the stop/destroy lifecycle on the SDK / EventSubscribe (which reaches native bcos_sdk_stop via RpcJniObj.stop()) crashes the JVM with SIGSEGV (process exit code 134).

Environment

• macOS arm64 (Apple Silicon) running the x86_64 fisco-bcos-macOS-x86_64 node and the SDK JNI via Rosetta 2
• bcos-sdk-jni 3.7.0, node v3.7.3, Java 8 (Zulu)

Crash (hs_err)

# A fatal error has been detected by the Java Runtime Environment:
#  SIGSEGV (0xb) ... SEGV_ACCERR
# Problematic frame:
# C  [libbcos-sdk-jni-aarch64.dylib+0x263bb0]  bcos_sdk_stop+0x140
Current thread: JavaThread "Test worker" [_thread_in_native]
  j  org.fisco.bcos.sdk.jni.rpc.RpcJniObj.stop()V+0
  j  <test that built an EventSubscribe/Client and then stopped it>

The crash is in native bcos_sdk_stop, triggered from the Java stop/destroy path — consistent with a use-after-free / double-stop on the native handle (related to the AMOP/eventsub lifecycle, where the JNI object may be stopped/freed more than once or while callbacks are in flight).

Impact

Apps or tests that build an SDK / EventSubscribe and then stop()/destroy() it can hard-crash the JVM. (It also silently wipes JaCoCo coverage data, because a native crash bypasses the JVM shutdown hook.)

Suggested investigation

Make the native stop path idempotent and null-/freed-checked (stop subscriptions before freeing the RPC object; guard against double bcos_sdk_stop). This may ultimately live in bcos-sdk-jni / bcos-c-sdk rather than this Java repo — feel free to transfer.

Found via

A filter/eventsub integration test that called stop()/destroy(), during #947.