runtime: should checkptrArithmetic accept a uintptr instead of unsafe.Pointer? #35379
Comments
|
@danscales, could this be related to open-coded |
|
CC @mdempsky The stack traces all show a call to |
|
It took 106 tries, but I was able to recreate the problem with |
|
Looks like with |
|
Could we isolate the bad pointer to a subprocess of the test, and have the test accept either the |
|
I think the issue here is that checkptrArithmetic takes the converted pointer as an unsafe.Pointer instead of uintptr. In the case of something like Normally this causes checkptrArithmetic to panic; but if it's interrupted by GC, then the runtime will fatal error instead. Two possible fixes:
|
|
Change https://golang.org/cl/205699 mentions this issue: |
|
Using |
|
Change https://golang.org/cl/205717 mentions this issue: |
|
@aclements I'm curious if you have any thoughts on the best code generation for the compiler to emit for checkptr. For something like: this is currently instrumented as: This is okay when the pointer arithmetic is correct (and I think necessary in case p points to the stack, and checkptrArithmetic causes it to grow). But when the pointer arithmetic is invalid, there's a chance that the runtime sees the bad pointer on the stack and throws instead (e.g., this issue). Probably checkptrArithmetic and checkptrBase should be or |
|
[Reopening to ensure the open questions above get answered.] |
bcmills
changed the title
|
Ping @aclements See question above. |
|
Is runtime throw really a bad thing? When there is a bad pointer, the point of checkptrArithmetic is to crash the program (I don't think we expect the user to catch such panic and do something with it). So it crashes either way, although the error message is less clear. Maybe the runtime could emit a different throw if the GC finds a bad pointer in checkptrArithmetic's frame? |
I'd be inclined to make checkptrArithmetic take a uintptr, since unsafe.Pointer should really only be used for "real", known-good pointers. But, of course, then we need to ensure the underlying pointer remains live. For that I'd lean toward your first option, as long as we can ensure checkptrArithmetic is recursively non-preemptible, and we can mark the whole region in the caller as non-preemptible (to prevent asynchronous preemption). But I don't think this is a big deal, either, and I think the current state is fine for 1.14. As @cherrymui pointed out, it's going to throw one way or the other, it could just be a nicer throw. |
|
@mdempsky, thank you for the questions and others too thanks for chiming in. @aclements on his last response acknowledged that the current state of affairs is fine for Go1.14, but with a recommendation/inclination to go with a runtime throw as @cherrymui recommended, perhaps we can explore these ideas for Go1.15 or later. Austin also removed the “release-blocker” label. With that, @ianlancetaylor @mdempsky should we perhaps move this issue out of the Go1.14 milestone, perhaps to Backlog? Thank you. |
|
Punting to Unreleased/Go1.17. |
|
@mdempsky Is there anything to do on this issue? I can't tell. |
|
This issue was reopened in #35379 (comment) to ensure the open questions above get answered. Moving to Backlog and assigning to @mdempsky to confirm if there's anything more left, or if it's okay to close this. |
Two instances of
darwin-amd64-race: https://build.golang.org/log/05f53140b89337ef848d51e83ffb8e19aabd27e0
linux-amd64-race (trybot): https://storage.googleapis.com/go-build-log/7828558a/linux-amd64-race_de2789c5.log
The text was updated successfully, but these errors were encountered: