Possible fuzz testing issue on Windows

124 views
Skip to first unread message

Tiago Katcipis

unread,
Apr 25, 2022, 1:17:24 AMApr 25
to golang-nuts
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

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:


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


The go version is show on the CI:



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

Kind regards,
Tiago Katcipis

Dan Kortschak

unread,
Apr 25, 2022, 1:40:30 AMApr 25
to golan...@googlegroups.com
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

unread,
Apr 25, 2022, 2:12:35 AMApr 25
to golan...@googlegroups.com
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

unread,
Apr 25, 2022, 8:42:59 AMApr 25
to golang-nuts
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

unread,
Apr 25, 2022, 5:22:56 PMApr 25
to golan...@googlegroups.com
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

unread,
Apr 27, 2022, 9:06:48 AMApr 27
to golang-nuts
Thanks for the prompt response + fix Dan 
 
Reply all
Reply to author
Forward
0 new messages