-
Notifications
You must be signed in to change notification settings - Fork 17.9k
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.
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
cmd/compile: bad escape analysis for linked data structures captured in closure #13799
Comments
CluesIf you move the If you add the following before the
Also, sometimes instead of the usual panic at the end of
I have also seen the following panic (less common):
|
I'll add some more details that haven't been mentioned already. We've tried running with However, some of the panics/errors like "fatal error: concurrent map read and map write" make it sound as if concurrency is somehow involved. Another note. Since func for iter := 0; ; iter += 4 {
if iter%48 == 0 {
fmt.Println(iter)
}
go test(iter)
go test(iter + 1)
go test(iter + 2)
test(iter + 3)
} In my testing, doing that makes the |
CC @dr2chase Could possibly be an escape analysis problem. |
This is weird. Here's the escape report (
(this is the working one)
My guess is that the bug occurs when the function escapes to heap but the map does not, and then the stack moves (because of recursion) and the heap-allocated closure is not updated. |
CL https://golang.org/cl/18234 mentions this issue. |
Run the following program:
Note: The constants are not special; as long as they are sufficiently large (above ~5), the behavior is exhibited.
The program should continue iterating indefinitely without triggering the panic at the end of
func test
, and indeed without panicking at all.On Go 1.5.2 and Go 1.6beta1 on darwin-amd64 and linux-amd64, the panic at the bottom of
func test
is triggered after anywhere between 1 and 4,000 iterations. Sometimes some other panics are seen (see "Clues" below).This is a possible compiler bug.
It continues iterating indefinitely without panics (as expected) on gccgo 4.9.1 on linux-amd64 and on GopherJS.
Thanks to @shurcooL for help in reproducing and isolating this issue.
The text was updated successfully, but these errors were encountered: