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

Jump to bottom

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

Closed
jeremyschlatter opened this issue Jul 8, 2015 · 9 comments
Closed

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

jeremyschlatter opened this issue Jul 8, 2015 · 9 comments
Labels
FrozenDueToAge Tools This label describes issues relating to any tools in the x/tools repository.
Milestone
Unreleased

Comments

@jeremyschlatter
Copy link
Contributor

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
Copy link
Contributor Author

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
Copy link
Contributor

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 pushed a commit to golang/tools that referenced this issue Jul 14, 2015
@adonovan
go/loader: issue informative error (not panic) if cgo used in ad hoc …
c5ca59a 
…package

See golang/go#11627.

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

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

@sbinet sbinet mentioned this issue Aug 10, 2015
Closed
@bradfitz
Copy link
Contributor

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
Copy link
Contributor

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
Copy link

evmar commented Dec 7, 2015

Filed #13526.

@pkorotkov
Copy link

Ping, any progress on this issue?

@alandonovan
Copy link
Contributor

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

@codeactual codeactual mentioned this issue May 31, 2017
Closed
@gcmurphy gcmurphy mentioned this issue Jan 27, 2018
Closed
@gopherbot gopherbot added the Tools This label describes issues relating to any tools in the x/tools repository. label Sep 12, 2019
@stamblerre
Copy link
Contributor

Since support golang.org/x/tools/go/loader is now deprecated, I'll go ahead and close this issue.

@golang golang locked and limited conversation to collaborators Apr 14, 2021
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Assignees
No one assigned
Labels
FrozenDueToAge Tools This label describes issues relating to any tools in the x/tools repository.
Projects
None yet
Milestone
Unreleased
Development

No branches or pull requests
8 participants
@bradfitz @evmar @josharian @pkorotkov @jeremyschlatter @stamblerre @alandonovan @gopherbot