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

runtime: unsafe.Slice panic is a throw in race/MSAN/ASAN modes #71397

Closed
prattmic opened this issue Jan 22, 2025 · 3 comments
Closed

runtime: unsafe.Slice panic is a throw in race/MSAN/ASAN modes #71397

prattmic opened this issue Jan 22, 2025 · 3 comments
Labels
compiler/runtime Issues related to the Go compiler and/or runtime. NeedsInvestigation Someone must examine and confirm this is a valid issue and not a duplicate of an existing one.
Milestone
Backlog

Comments

@prattmic
Copy link
Member

runtime.TestPanicOnUnsafeSlice tests panics on unsafe.Slice. It boils down to:

$ cd $GOROOT/src/runtime/testdata/testprog
$ go build
$ ./testprog panicOnNilAndEleSizeIsZero
panic: runtime error: unsafe.Slice: ptr is nil and len is not zero

goroutine 1 [running]:
main.panicOnNilAndEleSizeIsZero()
        /usr/local/google/home/mpratt/src/go/src/runtime/testdata/testprog/unsafe.go:11 +0xf
main.main()
        /usr/local/google/home/mpratt/src/go/src/runtime/testdata/testprog/main.go:34 +0x133

But if testprog is built with any of -race, -msan, or -asan, this panic becomes an unrecoverable throw:

$ go build -race
$ fatal error: unsafe.Slice: ptr is nil and len is not zero

goroutine 1 gp=0xc000002380 m=0 mp=0x6f6f20 [running]:
runtime.throw({0x5cbf7a?, 0x4b32a9?})
        /usr/local/google/home/mpratt/src/go/src/runtime/panic.go:1096 +0x48 fp=0xc00006ddc8 sp=0xc00006dd98 pc=0x4a92c8
runtime.panicCheck1(0x5a2420?, {0x5cbf7a, 0x2c})
        /usr/local/google/home/mpratt/src/go/src/runtime/panic.go:59 +0x94 fp=0xc00006dde8 sp=0xc00006ddc8 pc=0x470694
runtime.panicunsafeslicenilptr1(0xc00006de90?)
        /usr/local/google/home/mpratt/src/go/src/runtime/unsafe.go:113 +0x1f fp=0xc00006de10 sp=0xc00006dde8 pc=0x4a3cff
runtime.unsafeslice(0x59d860, 0x0, 0x5)
        /usr/local/google/home/mpratt/src/go/src/runtime/unsafe.go:61 +0x59 fp=0xc00006de28 sp=0xc00006de10 pc=0x4a3a99
runtime.unsafeslice64(0x4b1a59?, 0x4b3271?, 0x580d2c?)
        /usr/local/google/home/mpratt/src/go/src/runtime/unsafe.go:80 +0x13 fp=0xc00006de50 sp=0xc00006de28 pc=0x4a3b33
runtime.unsafeslicecheckptr(0x59d860, 0x0, 0x5)
        /usr/local/google/home/mpratt/src/go/src/runtime/unsafe.go:84 +0x25 fp=0xc00006de78 sp=0xc00006de50 pc=0x4a3b85
main.panicOnNilAndEleSizeIsZero()
        /usr/local/google/home/mpratt/src/go/src/runtime/testdata/testprog/unsafe.go:11 +0x2b fp=0xc00006dea0 sp=0xc00006de78 pc=0x585f4b
main.main()
        /usr/local/google/home/mpratt/src/go/src/runtime/testdata/testprog/main.go:34 +0x22c fp=0xc00006df50 sp=0xc00006dea0 pc=0x580d2c
runtime.main()
        /usr/local/google/home/mpratt/src/go/src/runtime/proc.go:283 +0x28b fp=0xc00006dfe0 sp=0xc00006df50 pc=0x47584b
runtime.goexit({})
        /usr/local/google/home/mpratt/src/go/src/runtime/asm_amd64.s:1700 +0x1 fp=0xc00006dfe8 sp=0xc00006dfe0 pc=0x4b0381

I suspect this is related to inlining, as panicCheck1 throws if pc is in the runtime, and pc ultimately comes from sys.GetCallerPC.

cc @golang/runtime @golang/compiler
@prattmic prattmic added the NeedsInvestigation Someone must examine and confirm this is a valid issue and not a duplicate of an existing one. label Jan 22, 2025
@prattmic prattmic added this to the Backlog milestone Jan 22, 2025
@gopherbot gopherbot added the compiler/runtime Issues related to the Go compiler and/or runtime. label Jan 22, 2025
@cherrymui
Copy link
Member

Race build implies checkptr, which makes the compiler insert a call of runtime.unsafestringcheckptr, which then calls unsafeslice64, which calls unsafeslice, which eventually calls panicunsafeslicenilptr1. The caller PC is captured in runtime.unsafeslice, which is too late, already two frames down into the runtime. Or, make unsafestringcheckptr just check the straddle, without calling unsafeslice64, leaving that to the compiler.

@prattmic
Copy link
Member Author

Doh, I missed the checkptr in runtime.unsafeslicecheckptr, thanks.

@prattmic prattmic closed this as not planned Won't fix, can't repro, duplicate, stale Jan 23, 2025
@cherrymui
Copy link
Member

I'm not sure checkptr should throw in this case. Currently it throws for the buggy unsafe pointer uses (which would not panic or throw in regular mode). This is turning a panic to a throw, so slightly different, but perhaps fine?

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees
No one assigned
Labels
compiler/runtime Issues related to the Go compiler and/or runtime. NeedsInvestigation Someone must examine and confirm this is a valid issue and not a duplicate of an existing one.
Projects
None yet
Milestone
Backlog
Development

No branches or pull requests
3 participants
@prattmic @gopherbot @cherrymui