test: bug369 failing on Plan 9

[0intro]

The test bug369 was enabled as part of change 1774.

It is failing on Plan 9, because the working directory
is changed between two go tool 8g calls.

The test is run from /usr/go/test. When running the test,
the working directly is firstly set to ./fixedbugs/bug369.dir
using os.Chdir, then it is reset to /usr/go/test after the first
successfull go tool 8g call.

term% cd /usr/go/test
term% go run run.go -- fixedbugs/bug369.go
# go run run.go -- fixedbugs/bug369.go
exit status: 'go 1364366: 1'
getwd /usr/go/test/fixedbugs/bug369.dir
go tool 8g -N -o slow.8 pkg.go
getwd /usr/go/test
go tool 8g -o fast.8 pkg.go
open pkg.go: 'pkg.go' file does not exist

exit status: 'go 1364381: 1'
exit status: 'bug369 1364373: 1'

FAIL    fixedbugs/bug369.go 1.578s
exit status: 'run 1364363: 1'

[0intro]

Actually, the path is correct every two go tool 8g run.

term% go run run.go -- fixedbugs/bug369.go
# go run run.go -- fixedbugs/bug369.go
incorrect output
getwd /usr/go/test/fixedbugs/bug369.dir
go tool 8g -N -o slow.8 pkg.go
getwd /usr/go/test
go tool 8g -o fast.8 pkg.go
open pkg.go: 'pkg.go' file does not exist

exit status: 'go 1372660: 1'
getwd /usr/go/test/fixedbugs/bug369.dir
go tool 8g -o main.8 main.go
main.go:13: can't find import: "./fast"

exit status: 'go 1372664: 1'
getwd /usr/go/test
go tool 8l -o a.exe main.8
cannot open file: main.8

exit status: 'go 1372668: 1'
getwd /usr/go/test/fixedbugs/bug369.dir
./a.exe

fork/exec ./a.exe: './a.exe' file does not exist

FAIL    fixedbugs/bug369.go 1.787s
exit status: 'run 1372642: 1'

[0intro]

When running this program, I can't see any call to syscall.Chdir in Go
(except the first explicit os.Chdir), or any chdir syscall using ratrace.

It works fine when specifying the working directory explicitly
with exec.Cmd.Dir when forking, instead of calling os.Chdir
in the parent. For example:

cmd := exec.Command(name, args...)
cmd.Dir = filepath.Join(".", "fixedbugs", "bug369.dir")
_, err := cmd.CombinedOutput()

[josharian]

I think there's a similar working directory problem with Windows. It'd be good to understand what it happening, but either way, perhaps we should switch to using exec.Cmd.Dir.

[bradfitz]

I'd rather understand the problem before hiding from it.

[0intro]

I don't think we should change this test. It is actually very useful to trigger this particular issue on Plan 9.

[bradfitz]

We should probably also add a specific test for this issue once it's understood.

[0intro]

I'm now able to reproduce this issue with a smaller
program, without having to run go tool 8g.

To reproduce this issue reliably, you need a first program
forking a second one, forking a third one.

• /tmp/proc1 https://play.golang.org/p/bmvVPB_Zpf
• /tmp/proc2 https://play.golang.org/p/76T-7JRpI8
• /tmp/proc3 https://play.golang.org/p/krdvVrzBe2

term% pwd
/usr/djc
term% /tmp/proc1
proc1 start
proc1 getwd /usr/djc
proc1 chdir /sys/src/9/pc
proc1 getwd /sys/src/9/pc
proc2 start
proc2 getwd /sys/src/9/pc
proc3 start
proc3 getwd /sys/src/9/pc
proc2 getwd /sys/src/9/pc
proc1 getwd /usr/djc

If you comment run("/tmp/proc3") in proc2, you get a race:

term% /tmp/proc1
proc1 start
proc1 getwd /usr/djc
proc1 chdir /sys/src/9/pc
proc1 getwd /sys/src/9/pc
proc2 start
proc2 getwd /sys/src/9/pc
proc2 getwd /sys/src/9/pc
proc1 getwd /usr/djc

term% /tmp/proc1
proc1 start
proc1 getwd /usr/djc
proc1 chdir /sys/src/9/pc
proc1 getwd /sys/src/9/pc
proc2 start
proc2 getwd /sys/src/9/pc
proc2 getwd /sys/src/9/pc
proc1 getwd /sys/src/9/pc

The final working directory in proc1 is either /usr/djc or /sys/src/9/pc.
I suspect there could be an issue somewhere in forkAndExecInChild.