runtime: Error related to `runtime.open_trampoline` in darwin/arm64

[richard-ramos]

What version of Go are you using (go version)?

$ go version
`go version go1.17.1 darwin/arm64`

Does this issue reproduce with the latest release?

Yes

What operating system and processor architecture are you using (go env)?

go env Output

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

What did you do?

• Cloned the repo: https://github.com/status-im/status-go
• Executed make statusgo-shared-library which does the following:

mkdir -p /Users/richard/status/status-desktop/vendor/status-go/build/bin/statusgo-lib
go run cmd/library/*.go > /Users/richard/status/status-desktop/vendor/status-go/build/bin/statusgo-lib/main.go
go build -buildmode=c-shared -o /Users/richard/status/status-desktop/vendor/status-go/build/bin/libstatus.dylib -ldflags=' -X github.com/status-im/status-go/params.Version=0.86.5 -X github.com/status-im/status-/go/params.GitCommit=07651d4d -X github.com/status-im/status-go/vendor/github.com/ethereum/go-ethereum/metrics.EnabledStr=true' /Users/richard/status/status-desktop/vendor/status-go/build/bin/statusgo-lib

• Used the resulting file libstatus.dylib in another program which executes the exported function callPrivateRPC() passing the following JSON:

{"jsonrpc":"2.0", "method": "wakuext_startMessenger", "params":[]}

What did you expect to see?

Expected to see the result of https://github.com/status-im/status-go/blob/0c0e02e93af31207fedb04f98ae6161cd4bcb3df/services/ext/api.go#L548-L550

What did you see instead?

Application crashes. When running the app with lldb, the following error is seen:

Process 5688 stopped
* thread #1, queue = 'com.apple.main-thread', stop reason = EXC_BAD_ACCESS (code=1, address=0x0)
    frame #0: 0x00000001022d9ca4 libstatus.dylibnotok + 4
libstatus.dylibnotok:
->  0x1022d9ca4 <+4>:  str    x8, [x8]
    0x1022d9ca8 <+8>:  b      0x1022d9ca8               ; <+8>
    0x1022d9cac <+12>: udf    #0x0
libstatus.dylib`runtime.open_trampoline:
    0x1022d9cb0 <+0>:  str    x30, [sp, #-0x10]!
Target 0: (nim_status_client) stopped.

[dr2chase]

@cherrymui

[cherrymui]

The fault doesn't happen in open_trampoline but in notok ( https://cs.opensource.google/go/go/+/master:src/runtime/sys_darwin_arm64.s;l=17 ) It intentionally faults when something bad happens when it shouldn't. The only places this is called are munmap fails, sigprocmask fails, sigaction fails, or sigaltstack fails. Could you get a stack trace to see how it got there? Thanks.

[richard-ramos]

Hello, @cherrymui,
Here's what I got after running thread backtrace 1

* thread #1, queue = 'com.apple.main-thread', stop reason = EXC_BAD_ACCESS (code=1, address=0x0)
  * frame #0: 0x00000001022d9c44 libstatus.dylib`notok + 4
    frame #1: 0x00000001022da270 libstatus.dylib`runtime.sigaltstack_trampoline + 32
    frame #2: 0x00000001022d9118 libstatus.dylib`runtime.asmcgocall + 200
    frame #3: 0x00000001022d9118 libstatus.dylib`runtime.asmcgocall + 200
    frame #4: 0x00000001022d9118 libstatus.dylib`runtime.asmcgocall + 200

Thank you!

[cherrymui]

This looks like sigaltstack fails, which is weird. Does the C (or other language) part of your binary (which links against the Go library) does anything weird about the signal stack? Could you provide more information about how you run the binary? Thanks.

[richard-ramos]

Does the C (or other language) part of your binary (which links against the Go library) does anything weird about the signal stack?

I use nim which translates to C. How can I identify if something is done with the signal stack?

[fzwoch]

Seeing similar here: fzwoch/obs-teleport#43

Happening with sigalstack as well as well as open.

A little context: OBS Studio is a C library with a C++ UI (Qt). It loads plugins via C interface and plugins can hook back into their system via a C interface too. So the plugin is build with -buildmode=c-shared.

This has been working fine for windows/x86_64, linux/x86_64, darwin/x86_64. OBS Studio recently release their first darwin/arm64 port where I noticed this issue.

[cherrymui]

Is the c-shared library used by a C/C++ program, or a Go program? Is it the only Go part in that program? Thanks.

[fzwoch]

The shared library is used by a C/C++ program. And yes, it is the only part in that system that is written in Go.

The application can be downloaded here:
https://github.com/obsproject/obs-studio/releases/tag/28.0.0-beta1

For the shared library to be loaded it can be placed in this location:
~/Library/Application\ Support/obs-studio/plugins/[shared_lib]/bin/[shared_lib].so

With [shared_lib] being something of your choice. The naming convention is important so that it gets loaded on startup. It also requires the .so extension instead of .dylib - I think that is due to some historic reason.

Opon running the application it freezes/hangs. When running from lldb one can see the Go runtime crash. Running with a debugger may require changing the app's entitlements though.

Alternatively that project can be build wiht its CI/build-macos.sh script.