cmd/go/internal/lockedfile: TestSpuriousEDEADLK flaky on plan9-arm since Oct. 7 #41952
Labels
FrozenDueToAge
NeedsInvestigation
Someone must examine and confirm this is a valid issue and not a duplicate of an existing one.
OS-Plan9
Milestone
Comments
bcmills
added
OS-Plan9
NeedsInvestigation
|
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. |
|
May be related to #48416 which also involves locking a file on /tmp. I'll try moving /tmp off ramfs on the plan9-arm builders for a while and see whether the failures stop. |
|
Duplicate of #48416. |
Sign up for free
to subscribe to this conversation on GitHub.
Already have an account?
Sign in.
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.TestSpuriousEDEADLKhas been failing sporadically on theplan9-armbuilder, apparently due to the failure of a*lockedfile.Fileto 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-0introbuilder started working again around then — do the-386-0introand-armbuilders 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: