go-fuzz-corpus
go-fuzz-corpus copied to clipboard
dvyukov
json: exclude panics from duplicate keys
go-fuzz finds the following crasher: "{\"o\":0,\"o\":null}". This doesn't survive an Unmarshal/Marshal round trip. However, this is working as intended: The second value for key o overwrites the first during Unmarshal, and thus the round-trip fails. See https://github.com/golang/go/issues/24415 for more discussion. We should teach the json Fuzz function that duplicate keys means a round trip failure is OK.
Adding my comment from golang/go#31309:
About this, I'm not sure we should consider this OK for the parser: what happens is that the field O **int is first filled with a value, then the last pointer of the chain is niled, while on the second unmarshal the first pointer of the chain is niled, hence the deep-equal failure.
This is valid behavior, but I find it inconsistent somewhat: I would expected both payloads to end-up with the same level of pointer being nil, not being dependent on the previous value of the field.
Discussion of how the json parser should handle particular inputs should probably happen in a new issue in the Go repo. (Sorry you keep getting bounced around.)
I expected it. I just wanted to keep this issue updated (or at least linked) because the project here spans so much it's a little hard to keep track of everything (I've spend half my free time yesterday bouncing around while discovering :P ).
I didn't see a new issue get filed, so just in case, cc @mvdan, who probably has opinions about the json parser's behavior.
I don't have an opinion unless someone opens an issue on the tracker with a specific problem or proposed change ;)
The decoder could certainly be taught an option to reject duplicate keys on maps and structs, though. That's the kind of thing I had in mind to fix https://github.com/golang/go/issues/14750 sometime in 1.14.
