x/mobile,runtime: missing stack trace on Android crash

[xcolwell]

Go version

go version go1.22.6 darwin/arm64

Output of go env in your module/workspace:

GO111MODULE=''
GOARCH='arm64'
GOBIN=''
GOCACHE='/Users/brien/Library/Caches/go-build'
GOENV='/Users/brien/Library/Application Support/go/env'
GOEXE=''
GOEXPERIMENT=''
GOFLAGS=''
GOHOSTARCH='arm64'
GOHOSTOS='darwin'
GOINSECURE=''
GOMODCACHE='/Users/brien/go/pkg/mod'
GONOPROXY=''
GONOSUMDB=''
GOOS='darwin'
GOPATH='/Users/brien/go'
GOPRIVATE=''
GOPROXY='https://proxy.golang.org,direct'
GOROOT='/usr/local/go'
GOSUMDB='sum.golang.org'
GOTMPDIR=''
GOTOOLCHAIN='auto'
GOTOOLDIR='/usr/local/go/pkg/tool/darwin_arm64'
GOVCS=''
GOVERSION='go1.22.6'
GCCGO='gccgo'
AR='ar'
CC='clang'
CXX='clang++'
CGO_ENABLED='1'
GOMOD='/dev/null'
GOWORK=''
CGO_CFLAGS='-O2 -g'
CGO_CPPFLAGS=''
CGO_CXXFLAGS='-O2 -g'
CGO_FFLAGS='-O2 -g'
CGO_LDFLAGS='-O2 -g'
PKG_CONFIG='pkg-config'
GOGCCFLAGS='-fPIC -arch arm64 -pthread -fno-caret-diagnostics -Qunused-arguments -fmessage-length=0 -ffile-prefix-map=/var/folders/r3/v_3z60rx2cxg0s1r9tl9fbmw0000gn/T/go-build4289722356=/tmp/go-build -gno-record-gcc-switches -fno-common'

What did you do?

Create a go module and build it with gomobile. For example, the build command below will produce an AAR file that can be bundled into an Android app.

cd /path/to/my/package
gomobile bind \
		-target=android/arm64 -androidapi 24 \
		-javapkg my.package \
		-trimpath \
		-gcflags="-dwarf=true" \
		-ldflags="-compressdwarf=false -B gobuildid" \
		-o build/android/MyPackage.aar \
	package/name

The build AAR can be bundled into an Android app with the build.gradle lines:

dependencies {
    compileOnly fileTree(dir: "/path/to/my/package/build/android", include: ['*-sources.jar'])
    implementation fileTree(dir: "/path/to/my/package/build/android", include: ['*.aar', '*.jar'])
}

What did you see happen?

Now if there is a crash from a goroutine inside the library, the following is printed to the Android logs. e.g. a nil pointer deference

2024-08-27 22:33:02.495 22477-22547 AndroidClassName                  my.package                I  init
2024-08-27 22:33:02.497 22477-0     Go                      my.package                E  panic: runtime error: invalid memory address or nil pointer dereference
--------- beginning of crash
2024-08-27 22:33:02.497 22477-0     Go                      my.package                E  [signal SIGSEGV: segmentation violation code=0x1 addr=0x10 pc=0x6f9cee6a0c]
2024-08-27 22:33:02.497 22477-22537 libc                    my.package                A  Fatal signal 6 (SIGABRT), code -6 (SI_TKILL) in tid 22537 (y.package), pid 22477 (y.package)

What did you expect to see?

I would expect to see a full stack trace similar to what happens when a go binary crashes. This is much more useful for crash logging and debugging.

[prattmic]

cc @hyangah

[prattmic]

cc @golang/runtime @golang/android

[gabyhelp]

Related Issues and Documentation

• x/mobile: SIGABRT when trying to call Go functions on Android #20827
• x/mobile, runtime: libgojni.so crashes on ARM64 devices for methods defined in Go code #65057 (closed)
• runtime: Crash on package init with fatal error: bad pointer in write barrier #15831 (closed)
• x/mobile: no current JVM #33254 (closed)
• x/mobile: bind with go1.22.5,1.22.6 leads to: fatal error: runtime: stack split at bad time #68760
• cmd/link: DWARF CFI rejected when function does not allocate stack space on ARM64 #35100
• affected/package: #63512 (closed)
• x/mobile libc : SIGABRT crash on the Genymotion Android emulator #29249 (closed)
• question: ARM v5 not working on Android with clang #29729 (closed)
• x/mobile: The sdk generated by gomobile cause crash in Android Q (API 29) #33715 (closed)

_{(Emoji vote if this was helpful or unhelpful; more detailed feedback welcome in this discussion.)}

[ignoramous]

Does this commit mean now stacktrace will be emitted as expected? 8203295

[xcolwell]

I'm exploring a proposal to improve errors in x/mobile generally - #70668

@ignoramous @hyangah I'd love your feedback on the proposal. I'm currently thinking x/mobile needs some improvement to unrecovered error handling. I'm curious how you are approaching this.