runtime: apparent memory corruption

[mitchellh]

Go version:
go version devel +4971493b0e14 Tue Oct 01 23:44:20 2013 -0400 darwin/amd64

Stack trace:
https://gist.github.com/mitchellh/8845f03f14706e3a49c2/raw/9b0655700830b5bad748478bdc67f61d28b92813/gistfile1.txt

This was the result of making a one-time HTTPS request to the AWS API. Running the
application again didn't result in the panic. I'm not sure what the response was that
caused this.

[robpike]

Comment 1:

If it's not reproducible, it could be (and looks like) memory corruption. Have you run
your program with -race?

Status changed to WaitingForReply.

[mitchellh]

Comment 2:

We run the "go test -race ./..." command in CI for every one of our commits, but
admittingly it doesn't reach this point in the code. But the part where this is failing
isn't even multi-threaded regarding any of the variables in that method.
The full stack trace is here, to show not many goroutines are doing much:
https://gist.github.com/MasonM/7103218/raw/860eb0cafe82d196cdde91befa0a0cd9396231ab/crash.log

[rsc]

Comment 3:

This looks like memory corruption or bad locking. issue #4869 was very similar, caused by
misaligned 64-bit atomics on 32-bit systems. However, you are on a 64-bit system so I
don't think that's the problem.
When issue #4869 came up I spent a long time reading the math/big division routines, and
I believe the code is correct. So this is probably another memory corruption, somehow.
Perhaps Dmitriy has an idea.
It is definitely concerning that you saw this. Please let us know if you can reproduce
it.

Labels changed: added priority-later, go1.2maybe, removed priority-triage.

Status changed to Accepted.

[dvyukov]

Comment 4:

I see nothing suspicious in the stack traces.
The values come from a slice, so probably heap is corrupted...

[rsc]

Comment 6:

In the absence of more information or a way to reproduce the problem, I think there's
nothing we can do.

Status changed to Unfortunate.