@yevgenypats, very nice to see you have picked up native dvyukov/go-fuzz support.

Regarding the playground error you were seeing, I suspect that the Error communicating with remote server error reported by your playground link might be due to timing out (or maybe some other error) when trying to download the fairly large github.com/dvyukov/go-fuzz-corpus dependency. (Being able to download third-party dependencies on the playground is still a fairly new feature, and it is not quite perfect yet, including around error messages if something goes wrong).

I tweaked your playground example to remove the direct import of github.com/dvyukov/go-fuzz-corpus, and it now successfully runs and reports the expected panic: zip: write to directory:

https://play.golang.org/p/h67gkTQnz8R

I changed the go-fuzz-corpus fuzz.DeepEqual to instead use reflect.DeepEqual. That is not always a valid transformation, e.g., from the doc:

// DeepEqual is reflect.DeepEqual except that:
// 1. nil and empty slice/string are considered equal
// 2. NaNs compare equal.

... but it should be OK here, I think. I also threw in a hex.DecodeString.

In any event, at least for now, playground links are a good way to share the reproducer, especially for now as people hopefully start to get more accustom to more fuzzing results for the stdlib.

(I saw these panics found by fuzzitbot via a tweet from @dvyukov, so people are probably starting to see this already, but I'll throw in a CC to @josharian and @FiloSottile in case interested.)

@yevgenypats for the asn1 panic, what exact version of dvyukov/go-fuzz-corpus/asn1/asn1.go are you using, or alternatively, could you post a playground link?

The line numbers in the reported panic don't seem to line up with the latest code in:

https://github.com/dvyukov/go-fuzz-corpus/blob/master/asn1/asn1.go

(But I also might be confused, or perhaps my Sunday AM coffee has not kicked in yet for me...).

From a very quick triage (or in other words, don't really trust this, and others should look more carefully.... Also, I'm not quite sure the line numbers line up, so I might be looking at the wrong code):

1. The first reported panic for github.com/dvyukov/go-fuzz-corpus/zip might be due to a failed round-trip validation with a mismatched header after compress/decompress.

2. The second reported panic for github.com/dvyukov/go-fuzz-corpus/zip might be due to a "user error" of attempting to write to a directory. There might be a need to guard against reporting that in the fuzz function. Alternatively, maybe that is an actual stdlib bug.

3. For the reported github.com/dvyukov/go-fuzz-corpus/asn1 panic, I can't quite see where it is panicking (e.g., maybe after an error was returned from asn1.Unmarshal, or maybe after an error was returned from asn1.Marshal, or somewhere else).

For the 1st zip panic (panic: corrupted header), I created this playground link:

https://play.golang.org/p/Ajt4bobuTwL

(That copies in the go-fuzz-corpus DeepEqual function, in contrast to the playground link above for the 2nd zip panic, which used reflect.DeepEqual directly).

Hey @thepudds thanks for the analysis!:)

using your instructions I've created another playground link for another crash (I'm not sure yet if it's a real problem or more of a problem in the fuzz functions itself though).

https://play.golang.org/p/DS-JC5JhbKG

@yevgenypats For the json panic you just posted at https://play.golang.org/p/DS-JC5JhbKG (panic number 4 overall here), I think that is due to duplicate keys not surviving the round-trip checks in the fuzz function, which is dvyukov/go-fuzz-corpus#3. That's expected behavior for the json package, e.g., see comment at #24415 (comment).

If that is correct, then that would be something to fix within the fuzz function.

Would you be able to post a playground link for the asn1 panic reported here?

Once you have confirmed repro steps for each package, would you mind filing separate issues for them (unless they have the same underlying cause)? Thanks.

Here is a playground link that I think corresponds to asn1 failure reported above: https://play.golang.org/p/6DqPzc84117

It looks like there is an asn1.Unmarshal that returns without error, and then the result is used in asn1.Marshal, which returns the asn1: string not valid UTF-8 error (which the Fuzz function sees and then calls panic).