Possible fuzz testing issue on Windows

[Tiago Katcipis]

Hi,

I was playing around with Go's fuzz support on a pet project of mine and as the fuzzer found some offending inputs it created the corpus entries on the file system. I fixed the issues but then something interesting happened on my CI pipeline, go test was failing only on windows and it was failing with a panic inside the call to f.Fuzz.

The code doing the fuzzing can be found here: https://github.com/madlambda/jtoh/blob/b2da122b83d791f0b1c2e81adb05c698d8772220/jtoh_fuzz_test.go#L111

Details on the error can be seen here: https://github.com/madlambda/jtoh/runs/5963485864?check_suite_focus=true#step:5:6

The panic message: "unmarshal: unknown encoding version: go test fuzz v1".

Following that I created a minimal project reproducing the issue:

https://github.com/katcipis/go-fuzz-win-issue/pull/1

The problem persists, nothing is done on the fuzz function:

https://github.com/katcipis/go-fuzz-win-issue/blob/main/fuzz_test.go

It works both on macos and linux (ubuntu 20.04), but it fails on both windows-2019/windows-2022 as can be seen here:

https://github.com/katcipis/go-fuzz-win-issue/runs/6085678496?check_suite_focus=true

The go version is show on the CI:

https://github.com/katcipis/go-fuzz-win-issue/runs/6085678496?check_suite_focus=true#step:3:6

Am I missing something obvious here or is there something wrong with fuzzing on Windows targets ? 

Kind regards,

Tiago Katcipis

[Dan Kortschak]

I suspect that this is from GitHub checking out the code on windows
with autocrlf and so converting perfectly sensible \n to \r\n, which is
then not properly handled by this
https://github.com/golang/go/blob/96c8cc7fea94dca8c9e23d9653157e960f2ff472/src/internal/fuzz/encoding.go#L105
.

It would be worth filing an issue for this.

Dan

[Dan Kortschak]

On Mon, 2022-04-25 at 05:39 +0000, 'Dan Kortschak' via golang-nuts
wrote:

>
> I suspect that this is from GitHub checking out the code on windows
> with autocrlf and so converting perfectly sensible \n to \r\n, which
> is
> then not properly handled by this
>
https://github.com/golang/go/blob/96c8cc7fea94dca8c9e23d9653157e960f2ff472/src/internal/fuzz/encoding.go#L105
> .
>
> It would be worth filing an issue for this.

I have sent https://go-review.googlesource.com/c/go/+/402074 to address
this.

Dan

[peterGo]

On Monday, April 25, 2022 at 2:12:35 AM UTC-4 kortschak wrote:

I have sent https://go-review.googlesource.com/c/go/+/402074 to address
this.

 

 Dan,

For the second and subsequent lines,

for _, line := range lines[1:] {
    line = bytes.TrimSpace(line)
    // ...
}

Did you consider being consistent and adopting that solution for the first line? For example,

line0 := bytes.TrimSpace(lines[0])
if string(line0) != encVersion1 {
    // . . .
}

Peter

Dan
 

[Dan Kortschak]

On Mon, 2022-04-25 at 05:42 -0700, peterGo wrote:
>
> Dan,
>
> For the second and subsequent lines,
>
> for _, line := range lines[1:] {
> line = bytes.TrimSpace(line)
> // ...
> }
>
> Did you consider being consistent and adopting that solution for the
> first line? For example,
>
> line0 := bytes.TrimSpace(lines[0])
> if string(line0) != encVersion1 {
> // . . .
> }
>

Yes, I did (and others), but felt the specific operation was both
clearer (particularly with the name used which explains what is being
looked at) and more correct.

Dan

[Tiago Katcipis]

Thanks for the prompt response + fix Dan