Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Jump to bottom

internal/fuzz: array literal initialization causes ICE "unhandled stmt ASOP" while fuzzing #56105

Closed
athomason opened this issue Oct 8, 2022 · 8 comments
Closed

internal/fuzz: array literal initialization causes ICE "unhandled stmt ASOP" while fuzzing #56105

athomason opened this issue Oct 8, 2022 · 8 comments
Assignees
@cuonglm
Labels
FrozenDueToAge NeedsFix The path to resolution is known, but the work has not been done.
Milestone
Go1.20

Comments

@athomason
Copy link

What version of Go are you using (go version)?

$ go version
go version go1.19.2 darwin/arm64

Does this issue reproduce with the latest release?

Yes:

$ gotip version
go version devel go1.20-40c7e94cc5 Fri Oct 7 20:20:51 2022 +0000 darwin/arm64

What operating system and processor architecture are you using (go env)?

darwin/arm64, linux/arm64

What did you do?

Run go test -fuzz . in a package containing this file:

https://go.dev/play/p/T2-Smn6iHXV

package main

import (
	"testing"
)

func TestSomething(t *testing.T) {
	_ = [...][]int{{}, {}, {}, {}, {}}
}

What did you expect to see?

Nothing.

What did you see instead?

$ go1.19.2 test -fuzz .
# asop [asop.test]
./asop_test.go:8:16: internal compiler error: 'TestSomething': unhandled stmt ASOP

Please file a bug report including a short program that triggers the error.
https://go.dev/issue/new
FAIL	asop [build failed]

$ gotip test -fuzz .
# asop [asop.test]
./asop_test.go:8:16: internal compiler error: 'TestSomething': unhandled stmt ASOP

goroutine 1 [running]:
runtime/debug.Stack()
	/Users/adam/go/gos/tip/src/runtime/debug/stack.go:24 +0x64
cmd/compile/internal/base.FatalfAt({0x3ee948?, 0x140?}, {0x140003ee920, 0x17}, {0x140007064a0, 0x2, 0x2})
	/Users/adam/go/gos/tip/src/cmd/compile/internal/base/print.go:227 +0x224
cmd/compile/internal/base.Fatalf(...)
	/Users/adam/go/gos/tip/src/cmd/compile/internal/base/print.go:196
cmd/compile/internal/ssagen.(*ssafn).Fatalf(0x0?, {0x4a66328?, 0x1?}, {0x104c49b61, 0x11}, {0x14000097d60, 0x1, 0x1400048d301?})
	/Users/adam/go/gos/tip/src/cmd/compile/internal/ssagen/ssa.go:7843 +0x154
cmd/compile/internal/ssagen.(*state).Fatalf(0x140000a4700?, {0x104c49b61?, 0x1400048d3f0?}, {0x14000097d60?, 0x14000800000?, 0x1044905d0?})
	/Users/adam/go/gos/tip/src/cmd/compile/internal/ssagen/ssa.go:938 +0x78
cmd/compile/internal/ssagen.(*state).stmt(0x140000a4700, {0x104e3dfa0, 0x1400006ea80?})
	/Users/adam/go/gos/tip/src/cmd/compile/internal/ssagen/ssa.go:2006 +0x2bcc
cmd/compile/internal/ssagen.(*state).stmtList(...)
	/Users/adam/go/gos/tip/src/cmd/compile/internal/ssagen/ssa.go:1423
cmd/compile/internal/ssagen.(*state).stmt(0x140000a4700, {0x104e3ee00, 0x14000705dc0?})
	/Users/adam/go/gos/tip/src/cmd/compile/internal/ssagen/ssa.go:1754 +0x363c
cmd/compile/internal/ssagen.(*state).stmtList(...)
	/Users/adam/go/gos/tip/src/cmd/compile/internal/ssagen/ssa.go:1423
cmd/compile/internal/ssagen.(*state).stmt(0x140000a4700, {0x104e3e058, 0x14000491590?})
	/Users/adam/go/gos/tip/src/cmd/compile/internal/ssagen/ssa.go:1438 +0x108
cmd/compile/internal/ssagen.(*state).stmtList(...)
	/Users/adam/go/gos/tip/src/cmd/compile/internal/ssagen/ssa.go:1423
cmd/compile/internal/ssagen.buildssa(0x1400048b900, 0x0)
	/Users/adam/go/gos/tip/src/cmd/compile/internal/ssagen/ssa.go:554 +0x1b88
cmd/compile/internal/ssagen.Compile(0x1400048b900, 0x140007063a0?)
	/Users/adam/go/gos/tip/src/cmd/compile/internal/ssagen/pgen.go:187 +0x30
cmd/compile/internal/gc.compileFunctions.func5.1(0x105678101?)
	/Users/adam/go/gos/tip/src/cmd/compile/internal/gc/compile.go:171 +0x3c
cmd/compile/internal/gc.compileFunctions.func2(0x0?)
	/Users/adam/go/gos/tip/src/cmd/compile/internal/gc/compile.go:125 +0x28
cmd/compile/internal/gc.compileFunctions.func5({0x140000aef58, 0x1, 0x1?})
	/Users/adam/go/gos/tip/src/cmd/compile/internal/gc/compile.go:170 +0x54
cmd/compile/internal/gc.compileFunctions()
	/Users/adam/go/gos/tip/src/cmd/compile/internal/gc/compile.go:181 +0x22c
cmd/compile/internal/gc.Main(0x104e334f0)
	/Users/adam/go/gos/tip/src/cmd/compile/internal/gc/main.go:311 +0x1368
main.main()
	/Users/adam/go/gos/tip/src/cmd/compile/main.go:57 +0xf4

FAIL	asop [build failed]

Notes

  • This is reduced from a larger table-driven test case in a package that had not previously had go fuzz run against it.
  • go build and go test have no problem with this code.
  • Four or fewer inner slices do not trigger the bug.
  • The bug is not present in 1.18.7, but is in 1.19.
  • Bisecting traces this back to 0bd7408 (https://go-review.googlesource.com/c/go/+/403995)
@athomason athomason changed the title internal/fuzz: slice literal initialization causes ICE "unhandled stmt ASOP" while fuzzing internal/fuzz: array literal initialization causes ICE "unhandled stmt ASOP" while fuzzing Oct 8, 2022
@athomason
Copy link
Author

On reading #52673 (comment), this definitely seems related to 0bd7408. @cuonglm I hope you don't mind a ping as the author there.

@cuonglm
Copy link
Member

cuonglm commented Oct 8, 2022

On reading #52673 (comment), this definitely seems related to 0bd7408. @cuonglm I hope you don't mind a ping as the author there.

Thanks for reporting.

I think the problem is just that the code generated for fuzzing is not properly process, commit 0bd7408 seems reveals the bug.

Will send the fix shortly.

@cuonglm cuonglm self-assigned this Oct 8, 2022
@cuonglm cuonglm added the NeedsFix The path to resolution is known, but the work has not been done. label Oct 8, 2022
@cuonglm cuonglm added this to the Go1.20 milestone Oct 8, 2022
@gopherbot
Copy link

Change https://go.dev/cl/440455 mentions this issue: cmd/compile: fix missing typecheck for libfuzzer instrumentation code

@cuonglm
Copy link
Member

cuonglm commented Oct 8, 2022

@mdempsky @randall77 should we backport this?

@mdempsky
Copy link
Member

mdempsky commented Oct 8, 2022

Looking briefly at the CL on my phone, it seems fine to backport yeah. Thanks for looking into it.

For the test case, can we just use a compile -d=libfuzzer test? Otherwise, maybe it should be a cmd/go script test.

@cuonglm
Copy link
Member

cuonglm commented Oct 8, 2022

For the test case, can we just use a compile -d=libfuzzer test? Otherwise, maybe it should be a cmd/go script test.

Ah right, forgot about -d=libfuzzer, I updated the test case. Thanks!

@gopherbot please backport this to go1.19

@gopherbot gopherbot mentioned this issue Oct 8, 2022
Closed
@gopherbot
Copy link

Backport issue(s) opened: #56106 (for 1.19).

Remember to create the cherry-pick CL(s) as soon as the patch is submitted to master, according to https://go.dev/wiki/MinorReleases.

@cuonglm
Copy link
Member

cuonglm commented Oct 10, 2022

On reading #52673 (comment), this definitely seems related to 0bd7408. @cuonglm I hope you don't mind a ping as the author there.

Thanks for reporting.

I think the problem is just that the code generated for fuzzing is not properly process, commit 0bd7408 seems reveals the bug.

Will send the fix shortly.

My first analysis is wrong, 0bd7408 actually introduces this bug. After ordering the static init codes, we still need to apply walk pass before appending them to parent init.

romaindoumenc pushed a commit to TroutSoftware/go that referenced this issue Nov 3, 2022
@cuonglm @romaindoumenc
cmd/compile: fix missing walk pass for static initialization slice
1f3c152 
CL 403995 fixed static init of literal contains dynamic exprs, by
ensuring their init are ordered properly. However, we still need to walk
the generated init codes before appending to parent init. Otherwise,
codes that requires desugaring will be unhandled, causing the compiler
backend crashing.

Fixes golang#56105

Change-Id: Ic25fd4017473f5412c8e960a91467797a234edfd
Reviewed-on: https://go-review.googlesource.com/c/go/+/440455
Reviewed-by: Matthew Dempsky <mdempsky@google.com>
Auto-Submit: Cuong Manh Le <cuong.manhle.vn@gmail.com>
TryBot-Result: Gopher Robot <gobot@golang.org>
Reviewed-by: Keith Randall <khr@google.com>
Run-TryBot: Cuong Manh Le <cuong.manhle.vn@gmail.com>
Reviewed-by: Keith Randall <khr@golang.org>
@randall77 randall77 mentioned this issue Nov 16, 2022
Closed
@cuonglm cuonglm mentioned this issue Dec 12, 2022
Closed
@golang golang locked and limited conversation to collaborators Oct 10, 2023
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Assignees

@cuonglm cuonglm

Labels
FrozenDueToAge NeedsFix The path to resolution is known, but the work has not been done.
Projects
None yet
Milestone
Go1.20
Development

No branches or pull requests
4 participants
@mdempsky @athomason @cuonglm @gopherbot