8000 runtime: bad "deadlock" fatal error when there are pending finalizers · Issue #41362 · golang/go · GitHub
[go: up one dir, main page]
More Web Proxy on the site http://driver.im/
Skip to content

runtime: bad "deadlock" fatal error when there are pending finalizers #41362

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
Open
mdempsky opened this issue Sep 13, 2020 · 0 comments
Open

runtime: bad "deadlock" fatal error when there are pending finalizers #41362

mdempsky opened this issue Sep 13, 2020 · 0 comments
Labels
compiler/runtime Issues related to the Go compiler and/or runtime. NeedsInvestigation Someone must examine and confirm this is a valid issue and not a duplicate of an existing one.
Milestone
Unplanned

Comments

@mdempsky
Copy link
Contributor
mdempsky commented Sep 13, 2020 •
edited
Loading

This program usually succeeds, but sometimes it fails with "fatal error: all goroutines are asleep - deadlock!":

package main

import "runtime"

func main() {
	ch := make(chan bool)

	x := [10]int{4}
	var f func(*int)
	f = func(p *int) {
		if *p == 0 {
			close(ch)
			return
		}
		*p--
		runtime.SetFinalizer(p, f)
	}
	runtime.SetFinalizer(&x[0], f)
	
	runtime.GC()
	runtime.GC()
	runtime.GC()
	runtime.GC()
	runtime.GC()

	<-ch
}

Adding an extra runtime.GC() call makes it reliably* succeed. Removing any makes it reliably* fail. (* Based on 1000 runs.)

I think the program should reliably succeed, even if all runtime.GC() calls are removed. That is, when the runtime scheduler notices there aren't any runnable goroutines, it should keep running GC cycles until a cycle finishes without running any user finalizers; and only then should it report deadlock if there still aren't any runnable goroutines.

I don't know of any real-world programs this affects, so maybe this isn't a high priority if it's difficult to address completely. But it would make writing robust compiler test cases somewhat easier (e.g., see golang.org/cl/254401).

/cc @aclements @ianlancetaylor
@mdempsky mdempsky added the NeedsInvestigation Someone must examine and confirm this is a valid issue and not a duplicate of an existing one. label Sep 13, 2020
@mdempsky mdempsky mentioned this issue Sep 15, 2020
Closed
@bcmills bcmills mentioned this issue Sep 16, 2020
Closed
@gopherbot gopherbot added the compiler/runtime Issues related to the Go compiler and/or runtime. label Jul 7, 2022
@mknyszek mknyszek moved this to Triage Backlog in Go Compiler / Runtime Jul 15, 2022
@seankhliao seankhliao added this to the Unplanned milestone Aug 27, 2022
@gabyhelp gabyhelp mentioned this issue Feb 18, 2025
Open
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees
No one assigned
Labels
compiler/runtime Issues related to the Go compiler and/or runtime. NeedsInvestigation Someone must examine and confirm this is a valid issue and not a duplicate of an existing one.
Projects
Go Compiler / Runtime
Status: Triage Backlog
Milestone
Unplanned
Development

No branches or pull requests
3 participants
@mdempsky @gopherbot @seankhliao
0