cmd/go/internal/lockedfile: TestSpuriousEDEADLK flaky on plan9-arm since Oct. 7 #41952
Labels
Milestone
Comments
While the plan9/386 builder is currently running a local ramfs (an "in memory" file system), I think the plan9/arm builders import their file system from a remote file server, so it may behave differently. |
In this test the file being locked is in /tmp, which the plan9_arm builders also mount on ramfs. |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
I'm not sure whether this is due to a change in the builder or a change in the runtime or standard library, but
lockedfile.TestSpuriousEDEADLK
has been failing sporadically on theplan9-arm
builder, apparently due to the failure of a*lockedfile.File
to provide the expected mutual-exclusion when open for writing.The first such failure occurred at CL 260137, but it's not obvious to me how that could be related. (The
plan9-386-0intro
builder started working again around then — do the-386-0intro
and-arm
builders share an underlying filesystem?)CC @millerresearch @fhs @0intro
2020-10-12T18:31:36-8994607/plan9-arm
2020-10-12T18:31:29-112c4d5/plan9-arm
2020-10-12T18:31:10-7b77ff4/plan9-arm
2020-10-12T18:31:01-5acec48/plan9-arm
2020-10-12T16:12:25-349a287/plan9-arm
2020-10-10T00:55:54-d317ba5/plan9-arm
2020-10-09T02:49:19-2be7788/plan9-arm
2020-10-09T02:14:32-8f26b57/plan9-arm
2020-10-09T01:09:06-f8df205/plan9-arm
2020-10-07T20:18:43-3f7b4d1/plan9-arm
2020-10-07T18:56:58-5c1567c/plan9-arm
2020-10-07T14:57:54-67edc0e/plan9-arm
The text was updated successfully, but these errors were encountered: