Go version

/arm64/libgojni.so (pc f0a3a8)

Output of go env in your module/workspace:

n/a

What did you do?

ran the com.beeper.android application, which is built with targetSdk 34, on an Android device running OS: google/husky/husky:15/BP1A.250305.019/2025040400. The app utilizes JNI calls that interface with the Go runtime via the native library libgojni.so. Within approximately 3 seconds of launch, the app crashed.

During startup, the process encountered memory corruption detected by Android’s Memory Tagging Extension (MTE). The crash log indicates that the segmentation fault (signal 11, SIGSEGV) occurred with code SEGV_MTESERR and fault address 700d43fe2c989e0, pinpointing an issue within libgojni.so (program counter at f0a3a8) in the DefaultDispatch thread.

The sequence of events is as follows:

App launch on an MTE-enabled device.

JNI interaction initiated by com.beeper.android.

Crash detected after ~3 seconds with detailed backtrace pointing to libgojni.so.

Crash attributes suggest memory tagging failures which highlight underlying memory corruption issues.

What did you see happen?

What did you see happen? The application terminated unexpectedly after a few seconds of startup. Key observations include:

Signal: 11 (SIGSEGV) is raised.

Error Code: 9 (SEGV_MTESERR) indicating a memory tagging extension error.

Fault Address: 700d43fe2c989e0, suggesting invalid memory access.

Thread: The crash was triggered in the DefaultDispatch thread.

Library Involved: The crash occurred in /lib/arm64/libgojni.so at PC offset f0a3a8.

The crash log indicates that the error was detected early in the application lifecycle (process uptime of about 3s).

What did you expect to see?

he intended behavior was a smooth launch and execution of the application without any crashes. Specifically:

The JNI calls to the Go runtime in libgojni.so should execute without memory-related errors.

Normal operation of the application, without triggering segmentation faults or memory corruption issues.

No interference from MTE diagnostics; the app should run stably on an MTE-enabled system.

Comment From: seankhliao

I think this should be reported to the application not to Go.

Comment From: cameronaaron

I think this is an issue with the native lib not the app