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/internal/obj: symbol redeclared panics during InitTextSym #68962

Open
y1yang0 opened this issue Aug 20, 2024 · 3 comments · May be fixed by #68963
Open

cmd/internal/obj: symbol redeclared panics during InitTextSym #68962

y1yang0 opened this issue Aug 20, 2024 · 3 comments · May be fixed by #68963
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

Comments

@y1yang0
Copy link
Contributor

y1yang0 commented Aug 20, 2024

Go version

go1.24

Output of go env in your module/workspace:

hidden

What did you do?

When compiling the automatically generated code(alibaba/opentelemetry-go-auto-instrumentation#52), a panic occurred:

/test.go:5:47: internal compiler error: panic: runtime error: invalid memory address or nil pointer dereference

Please file a bug report including a short program that triggers the error.
https://go.dev/issue/new

reproduce:

package otel_rules
import _ "unsafe"
import otel_debug "runtime/debug"
//go:linkname OtelPrintStack0 otel_debug.OtelPrintStack
func OtelPrintStack0() { otel_debug.PrintStack() }
//go:linkname OtelPrintStack1 otel_debug.OtelPrintStack
func OtelPrintStack1() { otel_debug.PrintStack() } 

further reduced:

package main
import _ "unsafe"

//go:linkname a main.c
func a() {}

func c() {}

stacktrace:

/go/mytest/bug.go:6:6: internal compiler error: panic: runtime error: invalid memory address or nil pointer dereference

goroutine 1 [running]:
runtime/debug.Stack()
        /go/src/runtime/debug/stack.go:26 +0x5e
cmd/compile/internal/base.FatalfAt({0x1936d8?, 0xc0?}, {0xe3824f, 0x9}, {0xc000193708, 0x1, 0x1})
        /go/src/cmd/compile/internal/base/print.go:230 +0x1ea
cmd/compile/internal/base.Fatalf(...)
        /go/src/cmd/compile/internal/base/print.go:195
cmd/compile/internal/gc.handlePanic()
        /go/src/cmd/compile/internal/gc/main.go:54 +0x8a
panic({0xdb0de0?, 0x14edc00?})
        /go/src/runtime/panic.go:785 +0x132
cmd/internal/obj.(*Link).InitTextSym(...)
        /go/src/cmd/internal/obj/plist.go:186
cmd/compile/internal/ir.setupTextLSym(0xfb1578?, 0xc0004fad01?)
        /go/src/cmd/compile/internal/ir/abi.go:77 +0x244
cmd/compile/internal/ir.InitLSym(0xc0004f8f00, 0x1)
        /go/src/cmd/compile/internal/ir/abi.go:32 +0xea
cmd/compile/internal/gc.prepareFunc(0xc0004f8f00)
        /go/src/cmd/compile/internal/gc/compile.go:95 +0x25
cmd/compile/internal/gc.enqueueFunc(0xc0004f8f00)
        /go/src/cmd/compile/internal/gc/compile.go:76 +0x268
cmd/compile/internal/gc.Main(0xe73238)
        /go/src/cmd/compile/internal/gc/main.go:300 +0x123b
main.main()
        /go/src/cmd/compile/main.go:57 +0xf9

In reduced program, both a and c have identical LSym, i.e. main.c.

When a has a body, setupTextLSym is called for the first time, initializing LSym.Extra at

s.NewFuncInfo()

Then, when processing c, setupTextLSym is called again. s.Func().Text was not initialized in the previous step by s.NewFuncInfo(), leading to the below panic

ctxt.Diag("%s: symbol %s redeclared\n\t%s: other declaration of symbol %s", ctxt.PosTable.Pos(start), s.Name, ctxt.PosTable.Pos(s.Func().Text.Pos), s.Name)

What did you see happen?

compiler panic

What did you expect to see?

not panic

@gopherbot gopherbot added the compiler/runtime Issues related to the Go compiler and/or runtime. label Aug 20, 2024
y1yang0 added a commit to y1yang0/go that referenced this issue Aug 20, 2024
Now the linker reports the following error message

/go/test/fixedbugs/issue68962.go:11:6: symbol main.c redeclared at
/go/test/fixedbugs/issue68962.go:13:6

Fixes golang#68962
@gopherbot
Copy link
Contributor

Change https://go.dev/cl/606903 mentions this issue: cmd/internal/obj: symbol redeclared panics during InitTextSym

@ianlancetaylor
Copy link
Member

Stack trace:

# command-line-arguments
foo.go:5:47: internal compiler error: panic: runtime error: invalid memory address or nil pointer dereference

goroutine 1 [running]:
runtime/debug.Stack()
	../../go/src/runtime/debug/stack.go:26 +0x5e
cmd/compile/internal/base.FatalfAt({0xe96d8?, 0xc0?}, {0xe36239, 0x9}, {0xc0000e9708, 0x1, 0x1})
	../../go/src/cmd/compile/internal/base/print.go:230 +0x1ea
cmd/compile/internal/base.Fatalf(...)
	../../go/src/cmd/compile/internal/base/print.go:195
cmd/compile/internal/gc.handlePanic()
	../../go/src/cmd/compile/internal/gc/main.go:54 +0x8a
panic({0xdaee20?, 0x14e8b40?})
	../../go/src/runtime/panic.go:785 +0x132
cmd/internal/obj.(*Link).InitTextSym(...)
	../../go/src/cmd/internal/obj/plist.go:186
cmd/compile/internal/ir.setupTextLSym(0xfaf078?, 0xc0003f7a01?)
	../../go/src/cmd/compile/internal/ir/abi.go:77 +0x244
cmd/compile/internal/ir.InitLSym(0xc0003c7400, 0x1)
	../../go/src/cmd/compile/internal/ir/abi.go:32 +0xea
cmd/compile/internal/gc.prepareFunc(0xc0003c7400)
	../../go/src/cmd/compile/internal/gc/compile.go:95 +0x25
cmd/compile/internal/gc.enqueueFunc(0xc0003c7400)
	../../go/src/cmd/compile/internal/gc/compile.go:76 +0x268
cmd/compile/internal/gc.Main(0xe711d8)
	../../go/src/cmd/compile/internal/gc/main.go:300 +0x123b
main.main()
	../../go/src/cmd/compile/main.go:57 +0xf9

@cherrymui cherrymui added this to the Unplanned milestone Aug 22, 2024
@cherrymui cherrymui added the NeedsInvestigation Someone must examine and confirm this is a valid issue and not a duplicate of an existing one. label Aug 22, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
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
Status: No status
Development

Successfully merging a pull request may close this issue.

5 participants