On Wed, 2020-03-11 at 05:25 +0000, Dan Kortschak wrote: > 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 >
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 -- 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/43e559673fe1419e54846a1277ae66635aba26b6.camel%40kortschak.io.
