go
go copied to clipboard
golang
runtime/race: cannot run under qemu-user-ppc64le due to execve /proc/self/exe
What version of Go are you using (go version)?
$ go version go version go1.15.2 linux/amd64
Does this issue reproduce with the latest release?
Yes, starting with go1.15rc2 up to the latest go1.15.3 release (that is, after https://github.com/golang/go/commit/e49b2308a523c3bb69753caee2eacce41f097039).
What did you do?
- Set up qemu-user on linux/amd64 host.
- Run
GOARCH=ppc64le go test.
What did you expect to see?
Tests running under QEMU user mode emulation.
What did you see instead?
qemu: unknown option 'test.timeout=10m0s'
The issue is caused by race detector runtime calling execve("/proc/self/exe", …). With user mode emulation this executes QEMU itself instead of the emulated process.
We currently lack a QEMU builder (#1508), and per http://golang.org/wiki/PortingPolicy, supported platforms require builders. Therefore, the QEMU platform is not supported.
Also, this is an issue with the race detector support libraries which are part of the LLVM project. There is nothing that the Go project can do to fix this problem.
CC @dvyukov
Indeed, that’s mostly an issue with sanitizer and not Go. Both are somewhat tightly coupled though. Concerning the fix, I think we can pass env var to indicate that the executable is run directly from go test (without intermediate “xprog”) and in that case use argv[0] instead of procfs path in LLVM’s ReExec.
Can I ask for an update on this? seems there were a couple of patches pushed out to qemu, to try and resolve, but I don't think they landed - is this an issue with qemu or with golang?
We don't seem to re-exec in Go mode at all: https://github.com/llvm/llvm-project/blob/539fa1df4634dad7d99e4485e4fc3a82ff1a5481/compiler-rt/lib/tsan/rtl/tsan_platform_linux.cpp#L267-L315
Does it still reproduce with the latest release?
Hi @dvyukov thanks for the reply - this is slightly academic for me at this point - I don't need qemu on my machine, but my team do and so this bug only occurs on other's machines. This issue predates me, I'm just trying to chase up on the status of the various patches on qemu's side as we are currently building custom qemu with those patches applied...
See the Qemu issue I raised for this here: https://gitlab.com/qemu-project/qemu/-/issues/1222
Perhaps there is some way we could look back through the go diffs and see if this was resolved for go at some point?