cmd/cgo: go 1.3 panics on recursive use of typedef #8368
Labels
Milestone
Comments
FYI ran into this one too. The following appears to have fixed it for me, though I'm
unsure if it's correct:
diff -r 9562b65a3c51 src/cmd/cgo/gcc.go
--- a/src/cmd/cgo/gcc.go Wed Jul 16 20:48:57 2014 +1000
+++ b/src/cmd/cgo/gcc.go Wed Jul 16 14:45:19 2014 +0200
@@ -1285,7 +1285,14 @@
if isStructUnionClass(sub.Go) {
// Use the typedef name for C code.
- typedef[sub.Go.(*ast.Ident).Name].C = t.C
+ n := sub.Go.(*ast.Ident).Name
+ if tmp := typedef[n]; tmp == nil {
+ tt := *t
+ tt.Go = sub.Go
+ typedef[n] = &tt
+
+ }
+ typedef[n].C = t.C
}
// If we've seen this typedef before, and it
|
Also, this issue might be a dup of 8238. FWIW $ clang --version Apple LLVM version 5.1 (clang-503.0.40) (based on LLVM 3.4svn) Target: x86_64-apple-darwin13.3.0 Thread model: posix $ uname -a Darwin thunder 13.3.0 Darwin Kernel Version 13.3.0: Tue Jun 3 21:27:35 PDT 2014; root:xnu-2422.110.17~1/RELEASE_X86_64 x86_64 |
Hi quarnster, Thanks for your patch. Could you please follow the contribution process defined here, http://golang.org/doc/contribute.html. Cheers Dave |
The issue here is similar to issue #8441: the dwarf.TypedefType case code expects when its recursive call to c.Type(dt.Type, pos) finishes that dt.Type has been fully translated already, but that's not the case if a structure type recursively refers to a typedef that refers to itself again. The patch from #2 stops the crash (but so would simply skipping the assignment if typedef[n] is nil), but I don't think it's otherwise correct. In particular, the "typedef[name.Name] = &tt" assignment from the dwarf.StructType case would clobber it. |
CL https://golang.org/cl/122850043 mentions this issue. |
|
This issue was closed by revision 0da4b2d. Status changed to Fixed. |
|
Issue #8238 has been merged into this issue. |
|
Issue #8238 has been merged into this issue. |
adg
added a commit
that referenced
this issue
May 11, 2015
««« CL 122850043 / 0015a2541545 cmd/cgo: fix recursive type mapping Instead of immediately completing pointer type mappings, add them to a queue to allow them to be completed later. This fixes issues caused by Type() returning arbitrary in-progress type mappings. Fixes #8368. Fixes #8441. LGTM=iant R=golang-codereviews, iant CC=golang-codereviews https://golang.org/cl/122850043 »»» TBR=rsc R=rsc CC=golang-codereviews https://golang.org/cl/128940043
wheatman
pushed a commit
to wheatman/go-akaros
that referenced
this issue
Jun 25, 2018
Instead of immediately completing pointer type mappings, add them to a queue to allow them to be completed later. This fixes issues caused by Type() returning arbitrary in-progress type mappings. Fixes golang#8368. Fixes golang#8441. LGTM=iant R=golang-codereviews, iant CC=golang-codereviews https://golang.org/cl/122850043
wheatman
pushed a commit
to wheatman/go-akaros
that referenced
this issue
Jul 9, 2018
Instead of immediately completing pointer type mappings, add them to a queue to allow them to be completed later. This fixes issues caused by Type() returning arbitrary in-progress type mappings. Fixes golang#8368. Fixes golang#8441. LGTM=iant R=golang-codereviews, iant CC=golang-codereviews https://golang.org/cl/122850043
This issue was closed.
Sign up for free
to subscribe to this conversation on GitHub.
Already have an account?
Sign in.
by Jonathan.Plona:
What does 'go version' print? go version go1.3 linux/amd64 What steps reproduce the problem? If possible, include a link to a program on play.golang.org. 1. Run go build on the attached files What happened? panic: runtime error: invalid memory address or nil pointer dereference [signal 0xb code=0x1 addr=0x0 pc=0x418efd] goroutine 16 [running]: runtime.panic(0x668940, 0x80ae73) /build/go/src/go-1.3/src/pkg/runtime/panic.c:279 +0xf5 main.(*typeConv).Type(0xc2080502c0, 0x7f77fdb76d10, 0xc2080a6b40, 0x150, 0xc208068401) /build/go/src/go-1.3/src/cmd/cgo/gcc.go:1288 +0x1f2d main.(*typeConv).Type(0xc2080502c0, 0x7f77fdb76ca0, 0xc2080a6ae0, 0x150, 0x72d540) /build/go/src/go-1.3/src/cmd/cgo/gcc.go:1189 +0x5a8e main.(*typeConv).Struct(0xc2080502c0, 0xc208004ba0, 0x150, 0x6, 0x0, 0x0, 0x0) /build/go/src/go-1.3/src/cmd/cgo/gcc.go:1551 +0x8e9 main.(*typeConv).Type(0xc2080502c0, 0x7f77fdb76cd8, 0xc208004ba0, 0x150, 0x1) /build/go/src/go-1.3/src/cmd/cgo/gcc.go:1234 +0x4646 main.(*typeConv).Type(0xc2080502c0, 0x7f77fdb76ca0, 0xc2080a69f0, 0x150, 0x72d540) /build/go/src/go-1.3/src/cmd/cgo/gcc.go:1189 +0x5a8e main.(*typeConv).Struct(0xc2080502c0, 0xc208004b40, 0x150, 0x6, 0x0, 0x0, 0x0) /build/go/src/go-1.3/src/cmd/cgo/gcc.go:1551 +0x8e9 main.(*typeConv).Type(0xc2080502c0, 0x7f77fdb76cd8, 0xc208004b40, 0x150, 0x1) /build/go/src/go-1.3/src/cmd/cgo/gcc.go:1234 +0x4646 main.(*Package).loadDWARF(0xc208001ba0, 0xc20804a080, 0xc20804e860, 0x3, 0x4) /build/go/src/go-1.3/src/cmd/cgo/gcc.go:541 +0x12e4 main.(*Package).Translate(0xc208001ba0, 0xc20804a080) /build/go/src/go-1.3/src/cmd/cgo/gcc.go:182 +0x1f0 main.main() /build/go/src/go-1.3/src/cmd/cgo/main.go:259 +0x1393 goroutine 19 [finalizer wait]: runtime.park(0x45f440, 0x8227c0, 0x80f649) /build/go/src/go-1.3/src/pkg/runtime/proc.c:1369 +0x89 runtime.parkunlock(0x8227c0, 0x80f649) /build/go/src/go-1.3/src/pkg/runtime/proc.c:1385 +0x3b runfinq() /build/go/src/go-1.3/src/pkg/runtime/mgc0.c:2644 +0xcf runtime.goexit() /build/go/src/go-1.3/src/pkg/runtime/proc.c:1445 What should have happened instead? It should build successfully. Please provide any additional information below. This code builds successfully with Go 1.2.2 Occasionally (maybe 5% of the time) the build command will succeed. Might be related to this bug: https://code.google.com/p/goncurses/issues/detail?id=18Attachments:
The text was updated successfully, but these errors were encountered: