go test -race hanging with Go1.14, only with -a flag

[Dan Kortschak]

I have a package that is dependent on bazil.org/fuse for testing via a
sysfs simulation package github.com/ev3go/sisyphus.

For historical reasons, the travis testing used the -a flag (since
removed because of the issue described here).

Since Go1.14, the standard runtime tests on travis passed, but the
-race tests hang. This is replicable on my local hardware (requiring a
reboot to continue working on the codebase since a fuse mount remains
after the hang, preventing access to the code directory).

Running tests on either bazil.org/fuse or the intermediate dependency
the same way does not cause the hang. This suggests to me that I'm
probably doing something wrong with a lock and I'm deadlocking the fuse
system in the kernel.

However, when I remove the -a flag from the go test -race invocation,
the tests complete and there is no complaint about data races. Nor does
the hang happen with Go versions prior to Go1.14.

Can anyone suggest why -a has this effect? or what has changed between
1.13 and 1.14 that might cause this? (Bisecting would be painful since
it requires a reboot between iterations).

The repository in question is github.com/ev3go/ev3dev and the PR that
illustrates the issue is https://github.com/ev3go/ev3dev/pull/90.

thanks
Dan

[Leszek Kubik]

I don’t know the -a flag and go help testflags doesn’t mention it.

I guess you turned off something in your tests

LK

--
You received this message because you are subscribed to the Google Groups "golang-nuts" group.
To unsubscribe from this group and stop receiving emails from it, send an email to golang-nuts...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/golang-nuts/83d84b29ce1969f0ea2aab6ac7e69e3d52b6c499.camel%40kortschak.io.

[Ian Lance Taylor]

I do not know what is happening, and what you are describing sounds
like a bug. The presence or absence of the -a flag should never
change the behavior of a program. In early Go releases the -a flag
was useful to force a rebuild of installed packages. But the last
several Go releases have used a build cache. If the -a flag changes
program behavior, that suggests that something is wrong with the build
cache. I suppose you could see whether `go clean -cache` fixes the
problem.

Ian

[Dan Kortschak]

I can be fairly confident that the build cache is not the problem; this
happens across a variety of machines (my local machine and the travis
infrastructure) and I have tried clearing the travis cache to no
benefit.

I agree this is likely a bug and was quite surprised by it for the
reason that you give. Unfortunately I am only able to reproduce this
with the full complexity of the ev3go/ev3dev tests, though I could
probably narrow it down to a specific test (hopefully). Should I file
an issue for this?

thanks
Dan

[Dan Kortschak]

OK. I just tried go clean -cache and it now does not hang. If I see
this again, I'll bump here, but at this point, it looks lost.

thanks
Dan