runtime: race in getitab (itab.init) #31419
Closed
Labels
Comments
Change https://golang.org/cl/171759 mentions this issue: |
Sign up for free
to subscribe to this conversation on GitHub.
Already have an account?
Sign in.
What version of Go are you using (
go version
)?tip (3cb92fc)
Does this issue reproduce with the latest release?
Yes
What operating system and processor architecture are you using (
go env
)?darwin/amd64, also linux/amd64
What did you do?
https://play.golang.org/p/3QdnC62q1Vb
What did you expect to see?
Not panic.
We do conversion of
e
(containing&t
) toI
concurrently, one with ",ok" form (inf1
), one without (inmain
).T
doesn't implementI
, so the conversion should fail, and the program should not panic.What did you see instead?
Panics.
After some iterations, the conversion in
main
succeeded, with anI
interface containing an&t
, which is bad.I think what happens here is:
getitab
callsm.init
to find out what method is missing for the panic message.m.init
writesm.fun[0]
toT.M
's code pointer as it sees theM
method. Before return it setsm.fun[0] = 0
as it couldn't find theM2
method. There is a small window thatm.fun[0]
is not 0.m.fun[0]
field ingetitab
. If this happens in the middle of the window thatm.fun[0]
is not 0, it thinks the conversion succeeded.I think we can fix this by not setting
m.fun[0]
immediately when we find the first method. Instead, store the code pointer in a variable, and setm.fun[0]
only after we know the conversion succeeds. Will send a fix.Found this while I'm porting itab caching to gccgo.
cc @aclements @randall77
The text was updated successfully, but these errors were encountered: