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

plugin: loaded packages can be inconsistent #17578

Closed
rogpeppe opened this issue Oct 25, 2016 · 2 comments
Closed

plugin: loaded packages can be inconsistent #17578

rogpeppe opened this issue Oct 25, 2016 · 2 comments
Labels
FrozenDueToAge NeedsFix The path to resolution is known, but the work has not been done.
Milestone

Comments

@rogpeppe
Copy link
Contributor

go version devel +2113c9a Tue Oct 25 07:51:17 2016 +0000 linux/amd64

I installed a package local/bar:

    package bar
    import "fmt"

    type T string

    func (t T) String() string {
            return "earlier compile (" + string(t) + ")"
    }

    func Bar() interface{} {
            // Call Println to prevent inlining.
            fmt.Println("earlier called")
            return T("earlier")
    }

Then I built this code in package local/foo in plugin mode
(note that I wanted to export func() interface{} but couldn't
because of issue 17140):

package main
import "local/bar"

var X interface{} = bar.Bar()

Then I changed the local/bar package to change all occurrences of
"earlier" to "later" and installed it again.

Then I ran this program:

package main
import (
    "fmt"
    "log"
    "local/bar"
    "plugin"
)

func main() {
    x0 := bar.Bar()
    x1 := get("/home/rog/src/go/src/local/foo/foo.so")
    fmt.Printf("x0 %q %T\n", x0, x0)
    fmt.Printf("x1 %q %T\n", x1, x1)
}

func get(path string) interface{} {
    p, err := plugin.Open(path)
    if err != nil {
        log.Fatal(err)
    }
    sym, err := p.Lookup("X")
    if err != nil {
        log.Fatal(err)
    }
    switch sym := sym.(type) {
    case *interface{}:
        return *sym
    default:
        log.Fatalf("unexpected type %T", sym)
        panic("not reached")
    }
}

After fixing the plugin.open function to take the basename
of the path (otherwise it seems you can't load the plugin from
an absolute path), this prints:

later called
earlier called
x0 "later compile (later)" bar.T
x1 "later compile (earlier)" bar.T

Note that the plugin has called the constructor from within the plugin
code, but the String method is called from within the package that
was current when plugin loader was compiled.

This seems potentially problematic - we could have a constructor and
a method that maintain an invariant between them, and this could result
in subtly (or blatantly!) broken code.

It seems odd to me that there are two versions of the same
function lurking around - isn't plugin loading meant to de-dupe
packages?

@rakyll rakyll added this to the Go1.8 milestone Oct 25, 2016
@crawshaw crawshaw self-assigned this Oct 26, 2016
@crawshaw
Copy link
Member

The plugin package should refuse to load a plugin where a common package varies in any way. (Same with the toolchain used to build the binary and host plugin.) There is machinery used by -buildmode=shared that I believe can be adopted to do this.

@quentinmit quentinmit added the NeedsFix The path to resolution is known, but the work has not been done. label Nov 7, 2016
@crawshaw
Copy link
Member

I believe this will be resolved by #17832.

@golang golang locked and limited conversation to collaborators Nov 12, 2017
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
FrozenDueToAge NeedsFix The path to resolution is known, but the work has not been done.
Projects
None yet
Development

No branches or pull requests

5 participants