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/cgo: go 1.3 panics on recursive use of typedef #8368

Closed
gopherbot opened this issue Jul 14, 2014 · 13 comments
Closed

cmd/cgo: go 1.3 panics on recursive use of typedef #8368

gopherbot opened this issue Jul 14, 2014 · 13 comments

Comments

@gopherbot
Copy link

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=18

Attachments:

  1. bug.h (116 bytes)
  2. bug.go (179 bytes)
@ianlancetaylor
Copy link
Contributor

Comment 1:

Labels changed: added repo-main, release-go1.3.1.

@quarnster
Copy link

Comment 2:

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

@quarnster
Copy link

Comment 3:

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

@davecheney
Copy link
Contributor

Comment 4:

Hi quarnster,
Thanks for your patch. Could you please follow the contribution process defined here,
http://golang.org/doc/contribute.html.
Cheers
Dave

@quarnster
Copy link

Comment 5:

Sorry, I don't have time over to do it proper I'm afraid.

@mdempsky
Copy link
Member

mdempsky commented Aug 5, 2014

Comment 6:

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.

@gopherbot
Copy link
Author

Comment 7:

CL https://golang.org/cl/122850043 mentions this issue.

@ianlancetaylor
Copy link
Contributor

Comment 8:

This issue was closed by revision 0da4b2d.

Status changed to Fixed.

@ianlancetaylor
Copy link
Contributor

Comment 9:

Issue #8238 has been merged into this issue.

@rsc
Copy link
Contributor

rsc commented Aug 11, 2014

Comment 10:

Worried about the size of the fix, but it has a good test and is fixing an intermittent
crash with no workaround.
Approved for Go 1.3.1.

@rsc
Copy link
Contributor

rsc commented Aug 11, 2014

Comment 11:

Issue #8238 has been merged into this issue.

@adg
Copy link
Contributor

adg commented Aug 11, 2014

Comment 12:

This issue was closed by revision 4e9360fa753d.

@adg
Copy link
Contributor

adg commented Aug 11, 2014

Comment 13:

Applied to release-branch.go1.3.

@rsc rsc added this to the Go1.3.1 milestone Apr 14, 2015
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
@golang golang locked and limited conversation to collaborators Jun 25, 2016
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.
Projects
None yet
Development

No branches or pull requests

7 participants