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.

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

cmd/link: panic: index out of range [23] with length 0 #49619

Closed
ALTree opened this issue Nov 16, 2021 · 10 comments
Closed

cmd/link: panic: index out of range [23] with length 0 #49619

ALTree opened this issue Nov 16, 2021 · 10 comments
Labels
NeedsInvestigation Someone must examine and confirm this is a valid issue and not a duplicate of an existing one. release-blocker
Milestone

Comments

@ALTree
Copy link
Member

ALTree commented Nov 16, 2021

$ gotip version
go version devel go1.18-6c36c332fe Tue Nov 16 18:36:59 2021 +0000 linux/amd64
package main

func f() any {
	var a []any
	return a[0]
}

func main() {
	f()
}
$ gotip build crash.go 

# command-line-arguments
panic: runtime error: index out of range [23] with length 0

goroutine 1 [running]:
cmd/link/internal/ld.decodetypeKind(...)
	/home/alberto/gotip/src/cmd/link/internal/ld/decodesym.go:53
cmd/link/internal/ld.(*dwctxt).newtype(0xc000110af0, 0x87df)
	/home/alberto/gotip/src/cmd/link/internal/ld/dwarf.go:537 +0x23e7
cmd/link/internal/ld.(*dwctxt).defgotype(0xc000110af0, 0x87df)
	/home/alberto/gotip/src/cmd/link/internal/ld/dwarf.go:528 +0x125
cmd/link/internal/ld.(*dwctxt).newtype(0xc000110af0, 0x37b7)
	/home/alberto/gotip/src/cmd/link/internal/ld/dwarf.go:659 +0xb29
cmd/link/internal/ld.(*dwctxt).defgotype(0xc000110af0, 0x37b7)
	/home/alberto/gotip/src/cmd/link/internal/ld/dwarf.go:528 +0x125
cmd/link/internal/ld.(*dwctxt).importInfoSymbol(0xc000110af0, 0x0?)
	/home/alberto/gotip/src/cmd/link/internal/ld/dwarf.go:1134 +0x33c
cmd/link/internal/ld.(*dwctxt).dwarfVisitFunction(0xc000110af0, 0x4?, 0xc0000a20d0)
	/home/alberto/gotip/src/cmd/link/internal/ld/dwarf.go:1717 +0x425
cmd/link/internal/ld.dwarfGenerateDebugInfo(0xc00004e000)
	/home/alberto/gotip/src/cmd/link/internal/ld/dwarf.go:1876 +0x1528
cmd/link/internal/ld.Main(_, {0x20, 0x20, 0x1, 0x7, 0x10, 0x0, {0x0, 0x0}, {0x67cbc1, ...}, ...})
	/home/alberto/gotip/src/cmd/link/internal/ld/main.go:273 +0xe73
main.main()
	/home/alberto/gotip/src/cmd/link/main.go:69 +0xfe5

cc @randall77 @cherrymui

@ALTree ALTree added NeedsInvestigation Someone must examine and confirm this is a valid issue and not a duplicate of an existing one. release-blocker labels Nov 16, 2021
@ALTree ALTree added this to the Go1.18 milestone Nov 16, 2021
@randall77
Copy link
Contributor

randall77 commented Nov 16, 2021

@thanm

go run works fine. go build doesn't. Seems DWARF related.

@thanm thanm self-assigned this Nov 16, 2021
@thanm
Copy link
Contributor

thanm commented Nov 16, 2021

What's going on here is that the type in question (type.go.builtin.any) is one of those basic builtins that the compiler expects will be emitted when we compile the runtime, so it doesn't bother to emit it for every package. See

https://go.googlesource.com/go/+/5e59d6ebd110a7c19770c7d996930ff379ba5726/src/cmd/compile/internal/reflectdata/reflect.go#1733

... meaning that it appears as unresolved at link time (we would get a similar failure mode if the compiler failed to emit an entry for "type.uintptr" when building the runtime, or some other core builtin type). Probably the easiest way to handle this would be force a reference to the type when building the runtime package, I'll send a CL.

What is a bit puzzling about this one is why it hasn't come up before? Not sure about that.

@thanm
Copy link
Contributor

thanm commented Nov 16, 2021

Wondering if this same thing could come up with other generics predefined types, maybe 'comparable'? I tried to construct a test case for that but ran into

test/fixedbugs/issue49619.go:17:10: interface is (or embeds) comparable

@gopherbot
Copy link

gopherbot commented Nov 16, 2021

Change https://golang.org/cl/364377 mentions this issue: cmd/compile: emit definition of 'any' when compiling runtime

@danscales
Copy link
Contributor

danscales commented Nov 17, 2021

This may be happening now because of @findleyr 's recent CL to try to preserve the 'any' type when converting from types2 to types1 (better error messages, etc.): https://go-review.googlesource.com/c/go/+/363974

@findleyr
Copy link
Contributor

findleyr commented Nov 17, 2021

I don't really understand the failure mode, but yes it seems highly likely that this is related to my CL. Before that change, I suspect we may never have produced types.AnyType.

@findleyr
Copy link
Contributor

findleyr commented Nov 17, 2021

We can revert that CL, of course, but it would be nice if we could fix forward; preserving the identity of any is a nice usability improvement.

@thanm
Copy link
Contributor

thanm commented Nov 17, 2021

@findleyr fix forward would be my choice. Compiler and linker already have a good deal of special cases for the runtime package when it comes to DWARF generation.

@findleyr
Copy link
Contributor

findleyr commented Nov 17, 2021

@thanm sounds good, thanks!

@gopherbot
Copy link

gopherbot commented Nov 17, 2021

Change https://golang.org/cl/364614 mentions this issue: cmd/compile: emit definition of 'any' only if generic enabled

gopherbot pushed a commit that referenced this issue Nov 17, 2021
CL 364377 emitted definition of 'any' when compiling runtime. But 'any'
is only available when generic enabled. Thus emitting its definition
unconditionally causes the compiler crashes.

Updates #49619

Change-Id: I0888ca1cbc7a7df300310a99a344f170636333f2
Reviewed-on: https://go-review.googlesource.com/c/go/+/364614
Trust: Cuong Manh Le <cuong.manhle.vn@gmail.com>
Trust: Dan Scales <danscales@google.com>
Run-TryBot: Cuong Manh Le <cuong.manhle.vn@gmail.com>
TryBot-Result: Go Bot <gobot@golang.org>
Reviewed-by: Dan Scales <danscales@google.com>
@rsc rsc unassigned thanm Jun 23, 2022
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
NeedsInvestigation Someone must examine and confirm this is a valid issue and not a duplicate of an existing one. release-blocker
Projects
None yet
Development

No branches or pull requests

6 participants