Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

runtime: Error related to runtime.open_trampoline in darwin/arm64 #48437

Open
richard-ramos opened this issue Sep 17, 2021 · 10 comments
Open

runtime: Error related to runtime.open_trampoline in darwin/arm64 #48437

richard-ramos opened this issue Sep 17, 2021 · 10 comments
Assignees
Labels
compiler/runtime Issues related to the Go compiler and/or runtime. NeedsInvestigation Someone must examine and confirm this is a valid issue and not a duplicate of an existing one.
Milestone

Comments

@richard-ramos
Copy link

richard-ramos commented Sep 17, 2021

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?

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.
@richard-ramos richard-ramos changed the title Error related to runtime.open_trampoline in darwing/arm64 Error related to runtime.open_trampoline in darwin/arm64 Sep 17, 2021
@dr2chase dr2chase added the NeedsInvestigation Someone must examine and confirm this is a valid issue and not a duplicate of an existing one. label Sep 20, 2021
@dr2chase
Copy link
Contributor

dr2chase commented Sep 20, 2021

@cherrymui

@cherrymui
Copy link
Member

cherrymui commented Sep 20, 2021

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
Copy link
Author

richard-ramos commented Sep 20, 2021

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
Copy link
Member

cherrymui commented Sep 21, 2021

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
Copy link
Author

richard-ramos commented Sep 21, 2021

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
Copy link

fzwoch commented Aug 6, 2022

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.

@seankhliao seankhliao changed the title Error related to runtime.open_trampoline in darwin/arm64 runtime: Error related to runtime.open_trampoline in darwin/arm64 Aug 6, 2022
@gopherbot gopherbot added the compiler/runtime Issues related to the Go compiler and/or runtime. label Aug 6, 2022
@cherrymui
Copy link
Member

cherrymui commented Aug 8, 2022

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
Copy link

fzwoch commented Aug 8, 2022

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.

@mknyszek mknyszek added this to the Backlog milestone Aug 10, 2022
@mknyszek
Copy link
Contributor

mknyszek commented Aug 10, 2022

@cherrymui Assigning to you for now since you last replied but please feel free to unassign!

@fzwoch
Copy link

fzwoch commented Sep 22, 2022

I tried again with most recent code from OBS. This time it crashes at

runtime.asmcgocall.abi0

->  0x161f8d7e8 <+200>: ldr    x2, [sp, #0x8]

(well it calls notok again, with the final crash):

->  0x161f8e384 <+4>:  str    x8, [x8]

Is there any special memory layout required for Go that the C++/Qt framework may break?

Interestingly enough, when I enable the Address Sanitizer from within Xcode and let the same code run it behaves perfectly fine. The Address Sanitizer also does not complain about anything being wrong or odd.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
compiler/runtime Issues related to the Go compiler and/or runtime. NeedsInvestigation Someone must examine and confirm this is a valid issue and not a duplicate of an existing one.
Projects
Status: Todo
Development

No branches or pull requests

6 participants