-
Notifications
You must be signed in to change notification settings - Fork 18k
runtime: fatal error: invalid stack pointer #12253
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
Comments
/cc @aclements (probably a dup of something you're already tracking, but... more data) |
@anacrolix, is there any use of cgo or unsafe in this program? Could you paste the rest of the stacks, or at least the stack that immediately followed the runtime stack? Did this happen just once or does it happen regularly, and if so, with what frequency? Is what you're running all open source and, if so, can you paste the commands I could use to get to the same place (and potentially reproduce the failure)? |
The main package isn't open source, most of the rest of it is: https://gist.github.com/anacrolix/f3434b0b3c587097ae31 I've just snipped out a few bits. It's only happened once, I've been tracking master on and off for months. This process instance ran for ~13 hours before this happened. I've used that go version previously. I dont use cgo or unsafe in any of my code, and I don't think any of my dependencies do. The process is a server, and I don't know what triggered it. But if you have any good guesses I can try to run those code paths. |
Thanks. Looks like the stack that's being adjusted is
The bad pointer is at fp-80 or sp+152 in processPacket (the assembly offsets will be slightly different, but I can never remember quite how). Looking at master (ef098c4), anacrolix/torrent/dht/dht.go:651 isn't an interface conversion (I actually don't see any interface conversions in that function, but maybe something got inlined). What commit of anacrolix/torrent were you running? If you still have the binary that crashed, can you run `go tool objdump -s Server..processPacket ' and paste the output? Could be bad stack maps around assertE2T2. @rsc |
Also, if you still have the binary, could you run
This will give us the DWARF information for processPacket so we don't have to reverse-engineer where the variables are. :) |
Could also be another manifestation of the bug fixed by c4092ac. |
I think I still have the binary, I'll get you that dump soon. |
@anacrolix, thanks for the DWARF dump. I'll need the objdump, too (#12253 (comment)). |
Yep, looks like another instance of the bug from c4092ac.
0x98(SP) was never zeroed. @rsc, do you know off the top of your head where this zeroing is missing? If not, I can dig. |
Something like this should help:
|
@anacrolix, can you try applying https://go-review.googlesource.com/13872 to see if that fixes the problem for you? |
CL https://golang.org/cl/13872 mentions this issue. |
CL https://golang.org/cl/14242 mentions this issue. |
…re of interface value A comparison of the form l == r where l is an interface and r is concrete performs a type assertion on l to convert it to r's type. However, the compiler fails to zero the temporary where the result of the type assertion is written, so if the type is a pointer type and a stack scan occurs while in the type assertion, it may see an invalid pointer on the stack. Fix this by zeroing the temporary. This is equivalent to the fix for type switches from c4092ac. Fixes #12253. Change-Id: Iaf205d456b856c056b317b4e888ce892f0c555b9 Reviewed-on: https://go-review.googlesource.com/13872 Reviewed-by: Russ Cox <rsc@golang.org> Reviewed-on: https://go-review.googlesource.com/14242 Reviewed-by: Austin Clements <austin@google.com>
go version devel +d931716 Tue Aug 18 00:55:16 2015 +0000 linux/amd64
The text was updated successfully, but these errors were encountered: