runtime: "fatal error: unexpected signal during runtime execution" on windows-amd64-longtest builder of Go 1.15.2 commit #41296
Comments
dmitshur
added
the
NeedsInvestigation
|
Oh, yeah, |
dmitshur
added
the
Testing
|
Change https://golang.org/cl/253777 mentions this issue: |
mknyszek
removed
the
NeedsInvestigation
dmitshur
added
the
NeedsFix
|
@mknyszek Does this need backporting? |
|
It's only an issue in our own tests, and it's going to be really rare because it requires the address space to be discontiguous (we do have tests that intentionally do make the address space discontiguous, but those don't run these particular functions). But, maybe that's a good reason to backport it too, to at least rule out this failure on release branches or folks running |
|
Let’s backport :) |
Sounds good! @gopherbot Please open a backport issue for 1.15. |
|
Backport issue(s) opened: #41317 (for 1.15). Remember to create the cherry-pick CL(s) as soon as the patch is submitted to master, according to https://golang.org/wiki/MinorReleases. |
|
Change https://golang.org/cl/253917 mentions this issue: |
|
@gopherbot Please open a backport issue for 1.14. |
|
Change https://golang.org/cl/253922 mentions this issue: |
…engedBits' chunk iteration Both ReadMemStatsSlow and CheckScavengedBits iterate over the page allocator's chunks but don't actually check if they exist. During the development process the chunks index became sparse, so now this was a possibility. If the runtime tests' heap is sparse we might end up segfaulting in either one of these functions, though this will generally be very rare. The pattern here to return nil for a nonexistent chunk is also useful elsewhere, so this change introduces tryChunkOf which won't throw, but might return nil. It also updates the documentation of chunkOf. For #41296. Fixes #41317. Change-Id: Id5ae0ca3234480de1724fdf2e3677eeedcf76fa0 Reviewed-on: https://go-review.googlesource.com/c/go/+/253777 Run-TryBot: Michael Knyszek <mknyszek@google.com> Reviewed-by: Keith Randall <khr@golang.org> TryBot-Result: Gobot Gobot <gobot@golang.org> (cherry picked from commit 34835df) Reviewed-on: https://go-review.googlesource.com/c/go/+/253917
…engedBits' chunk iteration Both ReadMemStatsSlow and CheckScavengedBits iterate over the page allocator's chunks but don't actually check if they exist. During the development process the chunks index became sparse, so now this was a possibility. If the runtime tests' heap is sparse we might end up segfaulting in either one of these functions, though this will generally be very rare. The pattern here to return nil for a nonexistent chunk is also useful elsewhere, so this change introduces tryChunkOf which won't throw, but might return nil. It also updates the documentation of chunkOf. For #41296. Fixes #41322. Change-Id: Id5ae0ca3234480de1724fdf2e3677eeedcf76fa0 Reviewed-on: https://go-review.googlesource.com/c/go/+/253777 Run-TryBot: Michael Knyszek <mknyszek@google.com> Reviewed-by: Keith Randall <khr@golang.org> TryBot-Result: Gobot Gobot <gobot@golang.org> (cherry picked from commit 34835df) Reviewed-on: https://go-review.googlesource.com/c/go/+/253922 Run-TryBot: Dmitri Shuralyov <dmitshur@golang.org> Reviewed-by: Michael Knyszek <mknyszek@google.com>
…engedBits' chunk iteration Both ReadMemStatsSlow and CheckScavengedBits iterate over the page allocator's chunks but don't actually check if they exist. During the development process the chunks index became sparse, so now this was a possibility. If the runtime tests' heap is sparse we might end up segfaulting in either one of these functions, though this will generally be very rare. The pattern here to return nil for a nonexistent chunk is also useful elsewhere, so this change introduces tryChunkOf which won't throw, but might return nil. It also updates the documentation of chunkOf. For golang#41296. Fixes golang#41317. Change-Id: Id5ae0ca3234480de1724fdf2e3677eeedcf76fa0 Reviewed-on: https://go-review.googlesource.com/c/go/+/253777 Run-TryBot: Michael Knyszek <mknyszek@google.com> Reviewed-by: Keith Randall <khr@golang.org> TryBot-Result: Gobot Gobot <gobot@golang.org> (cherry picked from commit 34835df) Reviewed-on: https://go-review.googlesource.com/c/go/+/253917
We've observed the following failure during
runtimetests on awindows-amd64-longtestslowbot on a commit for the upcoming Go 1.15.2:See here for more context and the complete build log.
The
windows-amd64-longtestslowbot passed all tests on the second try, so this failure is intermittent. It doesn't seem to happen often, but it may be connected to (or the same as) issues #41285, #41099.I've tried running
go test -timeout=0 -count=5 runtimeon a machine with Windows 10, and it passed.We should see if there's any useful information in this particular instance, and if not, this issue can probably be closed as a duplicate.
/cc @randall77 @ianlancetaylor @toothrot @andybons
The text was updated successfully, but these errors were encountered: