On Tue, 2020-03-10 at 22:07 -0700, Ian Lance Taylor wrote: > On Tue, Mar 10, 2020 at 3:25 AM Dan Kortschak <d...@kortschak.io> > wrote: > > > > 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. > > 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
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 -- 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+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/golang-nuts/43ea99e7d9d3a7150201564c19cfcf4b266afdc3.camel%40kortschak.io.
