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

x/tools/go/loader: panic loading cgo program #11627

Open
jeremyschlatter opened this issue Jul 8, 2015 · 8 comments
Open

x/tools/go/loader: panic loading cgo program #11627

jeremyschlatter opened this issue Jul 8, 2015 · 8 comments
Assignees
Labels
Milestone

Comments

@jeremyschlatter
Copy link
Contributor

@jeremyschlatter jeremyschlatter commented Jul 8, 2015

When trying to load a simple cgo program I get a panic: "internal error: unexpected import: C"

What version of Go are you using (go version)?

$ go version
go version go1.4.1 darwin/amd64

What operating system and processor architecture are you using?
OS X and amd64

$ uname -a
Darwin Jeremys-MacBook-Pro.local 14.3.0 Darwin Kernel Version 14.3.0: Mon Mar 23 11:59:05 PDT 2015; root:xnu-2782.20.48~5/RELEASE_X86_64 x86_64
$ go env GOOS
darwin
$ go env GOARCH
amd64

What did you do?

Ran this program:

package main

import "golang.org/x/tools/go/loader"

func main() {
    var conf loader.Config
    conf.CreateFromFilenames("main", "p.go")
    conf.Load()
}

Which loads this program:

package main

// typedef int (*intFunc) ();
//
// int
// bridge_int_func(intFunc f)
// {
//      return f();
// }
//
// int fortytwo()
// {
//      return 42;
// }
import "C"
import "fmt"

func main() {
    f := C.intFunc(C.fortytwo)
    fmt.Println(int(C.bridge_int_func(f)))
    // Output: 42
}

What did you expect to see?

The loading program run successfully.

What did you see instead?

$ go run load.go
panic: internal error: unexpected import: C [recovered]
    panic: internal error: unexpected import: C

goroutine 1 [running]:
golang.org/x/tools/go/types.(*Checker).handleBailout(0x208494000, 0x208439740)
    /Users/jeremy/src/golang.org/x/tools/go/types/check.go:219 +0xfc
golang.org/x/tools/go/loader.(*importer).doImport(0x2084554f0, 0x208480c80, 0x2084166f7, 0x1, 0x208438eb8, 0x0, 0x0)
    /Users/jeremy/src/golang.org/x/tools/go/loader/loader.go:716 +0x1d6
golang.org/x/tools/go/loader.func·007(0x208446e10, 0x2084166f7, 0x1, 0x1, 0x0, 0x0)
    /Users/jeremy/src/golang.org/x/tools/go/loader/loader.go:919 +0x5c
golang.org/x/tools/go/types.(*Checker).collectObjects(0x208494000)
    /Users/jeremy/src/golang.org/x/tools/go/types/resolver.go:189 +0x26fc
golang.org/x/tools/go/types.(*Checker).Files(0x208494000, 0x2084520a8, 0x1, 0x1, 0x0, 0x0)
    /Users/jeremy/src/golang.org/x/tools/go/types/check.go:229 +0xba
golang.org/x/tools/go/loader.(*importer).addFiles(0x2084554f0, 0x208480c80, 0x2084520a8, 0x1, 0x1, 0x0)
    /Users/jeremy/src/golang.org/x/tools/go/loader/loader.go:889 +0x25b
golang.org/x/tools/go/loader.func·003(0x281fc0, 0x4, 0x2084520a8, 0x1, 0x1, 0x208416660, 0x0, 0x1)
    /Users/jeremy/src/golang.org/x/tools/go/loader/loader.go:532 +0x151
golang.org/x/tools/go/loader.(*Config).Load(0x208480be0, 0x281fc0, 0x0, 0x0)
    /Users/jeremy/src/golang.org/x/tools/go/loader/loader.go:549 +0xcd9
main.main()
    /Users/jeremy/july7/load.go:8 +0xc1
exit status 2
@jeremyschlatter

This comment has been minimized.

Copy link
Contributor Author

@jeremyschlatter jeremyschlatter commented Jul 8, 2015

I reproduced the issue in a Linux VM:

$ go version
go version go1.3.1 linux/amd64
$ go run load.go
panic: internal error: unexpected import: C [recovered]
    panic: internal error: unexpected import: C

goroutine 16 [running]:
runtime.panic(0x5cb500, 0xc2080c7770)
    /usr/local/go/src/pkg/runtime/panic.c:279 +0xf5
golang.org/x/tools/go/types.(*Checker).handleBailout(0xc20806e000, 0x7f78af17a6f0)
    /home/vagrant/goworld/src/golang.org/x/tools/go/types/check.go:219 +0xcd
runtime.panic(0x5cb500, 0xc2080c7770)
    /usr/local/go/src/pkg/runtime/panic.c:248 +0x18d
golang.org/x/tools/go/loader.(*importer).doImport(0xc208019720, 0xc208042be0, 0xc208000527, 0x1, 0xc208000527, 0x0, 0x0)
    /home/vagrant/goworld/src/golang.org/x/tools/go/loader/loader.go:716 +0x1d9
golang.org/x/tools/go/loader.func·007(0xc208022d50, 0xc208000527, 0x1, 0x1, 0x0, 0x0)
    /home/vagrant/goworld/src/golang.org/x/tools/go/loader/loader.go:919 +0x5b
golang.org/x/tools/go/types.(*Checker).collectObjects(0xc20806e000)
    /home/vagrant/goworld/src/golang.org/x/tools/go/types/resolver.go:189 +0x237d
golang.org/x/tools/go/types.(*Checker).Files(0xc20806e000, 0xc208034078, 0x1, 0x1, 0x0, 0x0)
    /home/vagrant/goworld/src/golang.org/x/tools/go/types/check.go:229 +0xb7
golang.org/x/tools/go/loader.(*importer).addFiles(0xc208019720, 0xc208042be0, 0xc208034078, 0x1, 0x1, 0x0)
    /home/vagrant/goworld/src/golang.org/x/tools/go/loader/loader.go:889 +0x21c
golang.org/x/tools/go/loader.func·003(0x66de70, 0x4, 0xc208034078, 0x1, 0x1, 0xc208000440, 0x0, 0x1)
    /home/vagrant/goworld/src/golang.org/x/tools/go/loader/loader.go:532 +0x156
golang.org/x/tools/go/loader.(*Config).Load(0xc208042b40, 0x66de70, 0x0, 0x0)
    /home/vagrant/goworld/src/golang.org/x/tools/go/loader/loader.go:549 +0xac6
main.main()
    /home/vagrant/july7/load.go:8 +0xb9

goroutine 19 [finalizer wait]:
runtime.park(0x412ce0, 0x7b2e10, 0x7b1969)
    /usr/local/go/src/pkg/runtime/proc.c:1369 +0x89
runtime.parkunlock(0x7b2e10, 0x7b1969)
    /usr/local/go/src/pkg/runtime/proc.c:1385 +0x3b
runfinq()
    /usr/local/go/src/pkg/runtime/mgc0.c:2644 +0xcf
runtime.goexit()
    /usr/local/go/src/pkg/runtime/proc.c:1445
exit status 2
@josharian josharian added this to the Unreleased milestone Jul 8, 2015
@alandonovan

This comment has been minimized.

Copy link
Contributor

@alandonovan alandonovan commented Jul 14, 2015

Thanks for reporting this; I can reproduce it easily on Linux.

The problem is very simple but not simple to fix: go/loader only performs cgo preprocessing on imported packages, not ad hoc packages such as the one consisting of ["p.go"]. The workarounds is to move the cgo code into a separate package and import it. The fix is to rethink go/loader, which I will do after go1.5.


Notes to self: we need to copy and adapt the logic of goFilesPackage (from $GOROOT/src/cmd/go/build.go). Once this is done, all the loader.Config methods (Import and Create) will return the same kind of entity, essentially a build.Package. Perhaps we can even reuse this type directly.

Also: we should support swig.

alandonovan added a commit to golang/tools that referenced this issue Jul 14, 2015
…package

See golang/go#11627.

Change-Id: I458bc4ea54d0db34f3ba96060d284eda4bad7111
Reviewed-on: https://go-review.googlesource.com/12190
Reviewed-by: David Crawshaw <crawshaw@golang.org>
@alandonovan

This comment has been minimized.

Copy link
Contributor

@alandonovan alandonovan commented Jul 14, 2015

As a workaround I submitted this CL https://go-review.googlesource.com/#/c/12190/, which reports an internal error instead of panicking.

@bradfitz

This comment has been minimized.

Copy link
Contributor

@bradfitz bradfitz commented Dec 7, 2015

@alandonovan, is this the same bug as users being unable to use tools like gorename (which use x/tools/go/loader) with packages using cgo + pkg-config? @martine was asking me about this today and I had no clue.

@alandonovan

This comment has been minimized.

Copy link
Contributor

@alandonovan alandonovan commented Dec 7, 2015

No, this bug occurs only when files containing 'import "C"' appear on the command line, as opposed to being imported.

This is the first I've heard of the cgo + pkg-config problem, but now that you mention it, support for pkg--config is obviously missing. Feel free to file another issue for it.

@evmar

This comment has been minimized.

Copy link

@evmar evmar commented Dec 7, 2015

Filed #13526.

@pkorotkov

This comment has been minimized.

Copy link

@pkorotkov pkorotkov commented Nov 7, 2016

Ping, any progress on this issue?

@alandonovan

This comment has been minimized.

Copy link
Contributor

@alandonovan alandonovan commented Nov 7, 2016

Sorry, no. (The required fix is invasive and entails an API change.)

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Linked pull requests

Successfully merging a pull request may close this issue.

None yet
7 participants
You can’t perform that action at this time.