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
runtime: invalid stack pointer when parsing XML with atomic test coverage #16948
Comments
I was seeing a similar error in a number of tests I was running and hadn't been able to produce a more minimal test case yet, so I'm glad that you came up with this one. For the record, I'm pretty sure this is unrelated to both XML parsing and the covermode. |
Git bisect reports the offending commit as b2e0e96. |
It seems the problem is that the inserted atomic op (now as intrinsic, which produces <v, mem>) confuses the scheduler and makes following stores scheduled before the load of the return value of runtime.newobject. It was not a problem before this commit because the extra Zero op produces a mem, which happens to enforce the load is scheduled early. This Zero op is removed in this commit. I am working on it. |
CL https://golang.org/cl/28350 mentions this issue. |
BTW, I feel that this error message is not clear enough. It sounds like the value of SP is screwed. Maybe /cc @aclements |
CL https://golang.org/cl/28430 mentions this issue. |
Currently this message says "invalid stack pointer", which could be interpreted as the value of SP being invalid. Change it to "invalid pointer found on stack" to emphasize that it's a pointer on the stack that's invalid. Updates #16948. Change-Id: I753624f8cc7e08cf13d3ea5d9c790cc4af9fa372 Reviewed-on: https://go-review.googlesource.com/28430 Run-TryBot: Austin Clements <austin@google.com> TryBot-Result: Gobot Gobot <gobot@golang.org> Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org> Reviewed-by: Josh Bleecher Snyder <josharian@gmail.com>
What version of Go are you using (
go version
)?devel +f8555ea (HEAD)
What operating system and processor architecture are you using (
go env
)?Linux AMD64
What did you do?
The most minimal reproduction I can do tonight is these two files:
xmlparsing.go
xmlparsing.go
run
go test -covermode=atomic
What did you expect to see?
This is the output from Go 1.7 on the same system.
What did you see instead?
I didn't find any unsafe code in either the testing or encoding/xml packages, so this might be a memory corruption issue.
The text was updated successfully, but these errors were encountered: