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

Jump to bottom

runtime/race: cannot run under qemu-user-ppc64le due to execve /proc/self/exe #42080

Open
tie opened this issue Oct 20, 2020 · 6 comments
Open

runtime/race: cannot run under qemu-user-ppc64le due to execve /proc/self/exe #42080

tie opened this issue Oct 20, 2020 · 6 comments
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
Backlog

Comments

@tie
Copy link
Contributor

tie commented Oct 20, 2020 •
edited

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 e49b230).

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.
@tie tie changed the title runtime/race: regression under qemu-user-ppc64le due to execve /proc/self/exe runtime/race: cannot run under qemu-user-ppc64le due to execve /proc/self/exe Oct 20, 2020
@bcmills
Copy link
Contributor

bcmills commented Oct 20, 2020

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.

@ianlancetaylor
Copy link
Contributor

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

@tie
Copy link
Contributor Author

tie commented Oct 20, 2020 •
edited

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.

@cagedmantis cagedmantis added this to the Backlog milestone Oct 22, 2020
@cagedmantis cagedmantis added the NeedsInvestigation Someone must examine and confirm this is a valid issue and not a duplicate of an existing one. label Oct 22, 2020
@drakkan drakkan mentioned this issue Dec 9, 2020
Merged
@bcmills bcmills mentioned this issue Jan 13, 2022
Closed
@gopherbot gopherbot added the compiler/runtime Issues related to the Go compiler and/or runtime. label Jul 7, 2022
@samskiter
Copy link

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?

@dvyukov
Copy link
Member

dvyukov commented Sep 21, 2022

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?

@samskiter
Copy link

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?

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees
No one assigned
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
Go Compiler / Runtime
Status: Triage Backlog
Milestone
Backlog
Development

No branches or pull requests
7 participants
@cagedmantis @dvyukov @samskiter @ianlancetaylor @bcmills @gopherbot @tie