runtime: fault in runtime.mapiternext #14904
Comments
|
Go 1.5.3 is fine, Go 1.6 is fine. I'm trying to bisect now. |
|
I've bisected this as far as 481fe59. However, for possibly unrelated reasons, the test suite I am using to verify this fault does not run (fails to connect to the database on startup). I believe that this is an unrelated failure, but it prevents me from making a more accurate bisection. With that said, disabling ssa at this commit stops the crash. |
|
Please disregard the previous comment, the problem is much earlier than 481fe59 |
|
I'm sorry to report that the offending revision is 9d854fd, the SSA merge. If anyone wants to investigate I can configure a AWS VM with an environment to reproduce the problem. |
|
|
Setting |
|
This looks like corruption of the hash map header. The buckets field is junk. |
|
Current suspect: github.com/juju/juju/apiserver/client/status.go:(*statusContext).processService It's basically doing processedStatus = processedStatus using DUFFCOPY, but the VARDEF at the start tells the live variable analysis that processedStatus is dead before this code. Thus the GC won't scan any pointers in this structure, and it contains (among other things) maps. So named return values being copied to themselves in a return statement may be buggy. I'll try to make a small repro and a fix tomorrow. Changing "return processedStatus" to "return" fixed everything. Someone might want to do that to the juju sources, as it is better style and matches the other returns in the function. But I'll definitely fix this on the SSA end, we should generate correct code regardless. |
|
Thanks Keith. I'll make that change now as a workaround. On Thu, Mar 24, 2016 at 4:07 PM, Keith Randall notifications@github.com
|
apiserver/client: work around compiler bug with named return values Upstream golang/go#14904 Returning a complex variable by value with a mix of named and implicit returns was throwing off the compiler. This caused the memory occupied by the return value to be considered dead before the end of the function, leading to the gc freeing that memory prematurely. The bug is not believed to not affect any shipping Go 1.6 compiler, but it seems prudent to work around the compiler issue in our code. (Review request: http://reviews.vapour.ws/r/4336/)
|
CL https://golang.org/cl/21233 mentions this issue. |
Compound AUTO types weren't named previously. That was because live
variable analysis (plive.go) doesn't handle spilling to compound types.
It can't handle them because there is no valid place to put VARDEFs when
regalloc is spilling compound types.
compound types = multiword builtin types: complex, string, slice, and
interface.
Instead, we split named AUTOs into individual one-word variables. For
example, a string s gets split into a byte ptr s.ptr and an integer
s.len. Those two variables can be spilled to / restored from
independently. As a result, live variable analysis can handle them
because they are one-word objects.
This CL will change how AUTOs are described in DWARF information.
Consider the code:
func f(s string, i int) int {
x := s[i:i+5]
g()
return lookup(x)
}
The old compiler would spill x to two consecutive slots on the stack,
both named x (at offsets 0 and 8). The new compiler spills the pointer
of x to a slot named x.ptr. It doesn't spill x.len at all, as it is a
constant (5) and can be rematerialized for the call to lookup.
So compound objects may not be spilled in their entirety, and even if
they are they won't necessarily be contiguous. Such is the price of
optimization.
Re-enable live variable analysis tests. One test remains disabled, it
fails because of #14904.
Change-Id: I8ef2b5ab91e43a0d2136bfc231c05d100ec0b801
Reviewed-on: https://go-review.googlesource.com/21233
Run-TryBot: Keith Randall <khr@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: David Chase <drchase@google.com>
|
CL https://golang.org/cl/21470 mentions this issue. |
Please answer these questions before submitting your issue. Thanks!
go version)?go linux/amd64, rev d4663e1
go env)?linux/amd64
What did you do?
cd $GOPATH/src/github.com/juju/juju/cmd/juju/status
go test -i -v . && go test -count=20
Unfortunately reproducing this bug requires our monstrous test suite. For those who want to reproduce the issue I can setup a AWS instance with the correct dependencies.
tests pass
/cc @khr @aclements
The text was updated successfully, but these errors were encountered: