runtime/race: race detector truncates command-line arguments on ppc64le

[mdempsky]

When the program below is run with the race detector enabled, it truncates the command-line arguments list at the "" argument. In particular, this prevents using a race-detector-enabled cmd/compile on ppc64le, because cmd/go typically passes -D "".

I only see this on linux/ppc64le. I'm not able to reproduce the issue on linux/amd64.

$ go run hi.go -- one two "" three four
["/tmp/go-build2867456842/b001/exe/hi" "--" "one" "two" "" "three" "four"]
["one" "two" "" "three" "four"]

$ go run -race hi.go -- one two "" three four
["/tmp/go-build2206806436/b001/exe/hi" "--" "one" "two"]
["one" "two"]

package main

import (
	"flag"
	"fmt"
	"os"
)

func main() {
	fmt.Printf("%q\n", os.Args)
	flag.Parse()
	fmt.Printf("%q\n", flag.Args())
}

/cc @dvyukov

[gopherbot]

Change https://golang.org/cl/286173 mentions this issue: [dev.regabi] cmd/go: workaround -race issue on ppc64le

[cherrymui]

Just a guess: on some architectures, TSAN may re-exec the program (e.g. with ASLR disabled because it wants a specific memory layout). That re-exec might eat args. Maybe you could strace it to see if it re-exec? What is the output of ulimit -a on the machine?

[mdempsky]

Maybe you could strace it to see if it re-exec?

That does seem like the culprit:

$ strace -f ./hi one two "" three four |& grep exec
execve("./hi", ["./hi", "one", "two", "", "three", "four"], 0x7fffe4ef9d90 /* 40 vars */) = 0
execve("/proc/self/exe", ["./hi", "one", "two"], 0x7fff96060000 /* 40 vars */) = 0

What is the output of ulimit -a on the machine?

$ ulimit -a
core file size          (blocks, -c) unlimited
data seg size           (kbytes, -d) unlimited
scheduling priority             (-e) 0
file size               (blocks, -f) unlimited
pending signals                 (-i) 246242
max locked memory       (kbytes, -l) 65536
max memory size         (kbytes, -m) unlimited
open files                      (-n) 1024
pipe size            (512 bytes, -p) 8
POSIX message queues     (bytes, -q) 819200
real-time priority              (-r) 0
stack size              (kbytes, -s) 8192
cpu time               (seconds, -t) unlimited
max user processes              (-u) 246242
virtual memory          (kbytes, -v) unlimited
file locks                      (-x) unlimited

[cherrymui]

It's probably ASLR. Maybe you could try disable ASLR?

It is probably a bug in the re-exec code in TSAN.

[mdempsky]

Yeah, looks like it's from TSAN working around ASLR:

$ ./hi one two "" three four
["./hi" "one" "two"]
["one" "two"]

$ setarch `uname -m` -R ./hi one two "" three four
["./hi" "one" "two" "" "three" "four"]
["one" "two" "" "three" "four"]