Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Jump to bottom

runtime: bad P in runqempty called from checkRunqsNoP #47304

Closed
mknyszek opened this issue Jul 20, 2021 · 3 comments
Closed

runtime: bad P in runqempty called from checkRunqsNoP #47304

mknyszek opened this issue Jul 20, 2021 · 3 comments
Labels
FrozenDueToAge NeedsFix The path to resolution is known, but the work has not been done.
Milestone
Go1.17

Comments

@mknyszek
Copy link
Contributor

In trying to reproduce #47302 I wrote a little program. I failed to reproduce it, but instead I found a new failure.

The program is:

package main

import (
	"runtime"
	"time"
)

var sink []byte
var sink2 []byte

func main() {
	go func() {
		for {
			sink = make([]byte, 1024)
		}
	}()
	go func() {
		for {
			sink2 = make([]byte, 1024)
		}
	}()
	for i := 0; i < 5; i++ {
		time.Sleep(100 * time.Millisecond)
		runtime.GOMAXPROCS(100)
		time.Sleep(100 * time.Millisecond)
		runtime.GOMAXPROCS(4)
		time.Sleep(100 * time.Millisecond)
		runtime.GOMAXPROCS(6)
	}
}

The failure is:

fatal error: unexpected signal during runtime execution
[signal SIGSEGV: segmentation violation code=0x1 addr=0x5f0 pc=0x434824]

runtime stack:
runtime.throw({0x4696a7, 0x100000081})
	/usr/local/google/home/mknyszek/toolchain/src/runtime/panic.go:1198 +0x71
runtime.sigpanic()
	/usr/local/google/home/mknyszek/toolchain/src/runtime/signal_unix.go:719 +0x396
runtime.runqempty(...)
	/usr/local/google/home/mknyszek/toolchain/src/runtime/proc.go:5922
runtime.checkRunqsNoP({0xc000026000, 0x180, 0x4}, {0xc000018058, 0x7ffcc3668c48, 0x41e725})
	/usr/local/google/home/mknyszek/toolchain/src/runtime/proc.go:3091 +0x84
runtime.findrunnable()
	/usr/local/google/home/mknyszek/toolchain/src/runtime/proc.go:2891 +0x425
runtime.schedule()
	/usr/local/google/home/mknyszek/toolchain/src/runtime/proc.go:3367 +0x239
runtime.park_m(0xc000001380)
	/usr/local/google/home/mknyszek/toolchain/src/runtime/proc.go:3516 +0x14d
runtime.mcall()
	/usr/local/google/home/mknyszek/toolchain/src/runtime/asm_amd64.s:307 +0x43

goroutine 1 [sleep]:
time.Sleep(0x5f5e100)
	/usr/local/google/home/mknyszek/toolchain/src/runtime/time.go:193 +0x12e
main.main()
	/usr/local/google/home/mknyszek/tmp/gmp.go:25 +0x5b

goroutine 5 [runnable]:
main.main.func1()
	/usr/local/google/home/mknyszek/tmp/gmp.go:14 +0x28
created by main.main
	/usr/local/google/home/mknyszek/tmp/gmp.go:12 +0x26

goroutine 6 [runnable]:
main.main.func2()
	/usr/local/google/home/mknyszek/tmp/gmp.go:19 +0x28
created by main.main
	/usr/local/google/home/mknyszek/tmp/gmp.go:17 +0x34

I can reproduce this at tip, and going back about a month. It takes about 90 minutes (sometimes more, sometimes less) to reproduce when running under https://pkg.go.dev/golang.org/x/tools/cmd/stress. I don't think this is a release blocker because we've never seen it out in the wild, and this program is very unrealistic. It may also reproduce with older releases, I'm not sure.
@mknyszek mknyszek added the NeedsInvestigation Someone must examine and confirm this is a valid issue and not a duplicate of an existing one. label Jul 20, 2021
@mknyszek mknyszek added this to the Backlog milestone Jul 20, 2021
@mknyszek
Copy link
Contributor Author

CC @prattmic

@gopherbot
Copy link

Change https://golang.org/cl/336449 mentions this issue: runtime: move mem profile sampling into m-acquired section

@dmitshur dmitshur modified the milestones: Backlog, Go1.17 Jul 26, 2021
@dmitshur dmitshur added NeedsFix The path to resolution is known, but the work has not been done. and removed NeedsInvestigation Someone must examine and confirm this is a valid issue and not a duplicate of an existing one. labels Jul 26, 2021
@aclements aclements mentioned this issue Sep 9, 2021
Closed
@gopherbot
Copy link

Change https://golang.org/cl/359796 mentions this issue: runtime: add always-preempt maymorestack hook

gopherbot pushed a commit that referenced this issue Nov 5, 2021
@aclements
runtime: add always-preempt maymorestack hook
35c7234 
This adds a maymorestack hook that forces a preemption at every
possible cooperative preemption point. This would have helped us catch
several recent preemption-related bugs earlier, including #47302,
 #47304, and #47441.

For #48297.

Change-Id: Ib82c973589c8a7223900e1842913b8591938fb9f
Reviewed-on: https://go-review.googlesource.com/c/go/+/359796
Trust: Austin Clements <austin@google.com>
Run-TryBot: Austin Clements <austin@google.com>
TryBot-Result: Go Bot <gobot@golang.org>
Reviewed-by: Cherry Mui <cherryyz@google.com>
Reviewed-by: Michael Pratt <mpratt@google.com>
Reviewed-by: David Chase <drchase@google.com>
@golang golang locked and limited conversation to collaborators Oct 30, 2022
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Assignees
No one assigned
Labels
FrozenDueToAge NeedsFix The path to resolution is known, but the work has not been done.
Projects
None yet
Milestone
Go1.17
Development

No branches or pull requests
3 participants
@mknyszek @dmitshur @gopherbot