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/link: go 1.16 plugin does not initialize global variables correctly when not used directly #44956

Closed
metalwolf opened this issue Mar 12, 2021 · 8 comments
Labels
Milestone

Comments

@metalwolf
Copy link

@metalwolf metalwolf commented Mar 12, 2021

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

$ go version
go version go1.16.1 linux/amd64

Does this issue reproduce with the latest release?

yes
It actually appeared with the latest issue, was not happening in older versions ( <= 1.15)

What operating system and processor architecture are you using (go env)?

go env Output
$ go env
GO111MODULE=""
GOARCH="amd64"
GOBIN="/home/sites/go/bin"
GOCACHE="/root/.cache/go-build"
GOENV="/root/.config/go/env"
GOEXE=""
GOFLAGS=""
GOHOSTARCH="amd64"
GOHOSTOS="linux"
GOINSECURE=""
GOMODCACHE="/home/sites/go/pkg/mod"
GONOPROXY=""
GONOSUMDB=""
GOOS="linux"
GOPATH="/home/sites/go"
GOPRIVATE=""
GOPROXY="https://proxy.golang.org,direct"
GOROOT="/usr/local/go"
GOSUMDB="sum.golang.org"
GOTMPDIR=""
GOTOOLDIR="/usr/local/go/pkg/tool/linux_amd64"
GOVCS=""
GOVERSION="go1.16.1"
GCCGO="gccgo"
AR="ar"
CC="gcc"
CXX="g++"
CGO_ENABLED="1"
GOMOD="/home/sites/webability-go/test/go.mod"
CGO_CFLAGS="-g -O2"
CGO_CPPFLAGS=""
CGO_CXXFLAGS="-g -O2"
CGO_FFLAGS="-g -O2"
CGO_LDFLAGS="-g -O2"
PKG_CONFIG="pkg-config"
GOGCCFLAGS="-fPIC -m64 -pthread -fmessage-length=0 -fdebug-prefix-map=/tmp/go-build2426045409=/tmp/go-build -gno-record-gcc-switches"

What did you do?

I have build 2 plugins, using the same import module
The import module file set up a &map[string]*struct{} as a global variable, set by Containers = &map[string]*Container{}
Container can be any random struct
It exists another global variable Others = 123

The first plugin, just make a print of global variable 'Others' without addressing Containers from the import module
The second plugin uses the Containers global variable.

Strangely on this scheme, the second plugin gets a *map[string]*Container as NIL instead of a pointer to the structure.
When the Containers variable is used from the first plugin, anything works correctly and all the global variables are correctly set.

This error appreats in Go 1.16, was not happening in any previous version (tested to work correctly on 1.15 and 1.14)

What did you expect to see?

A correct implementation of the *map[string]*struct , pointing an existing map instead of a NIL of the map

What did you see instead?

a pointer to the NIL of the map instead of the map

I join the gzip of the 6 files environment

On GO 1.15.8:
[root@mexico test]# ./start.sh
213
START PLUG 2: &base.ContainersList{} 0x7fe6cb390b80 0xc000094210

Works correctly, the *Containers contains the pointer to the map

On GO 1.16.1:
[root@mexico test]# ./start.sh
213
START PLUG 2: &base.ContainersList(nil) 0x7f02a2329ca0 0x0

You will note the 0x0 as the NIL pointer of the *base.Containers contents. which is not initialized correctly

Code to reproduce the error:

test.zip

@cherrymui
Copy link
Contributor

@cherrymui cherrymui commented Mar 12, 2021

The code you attached doesn't include package "base". Could you include that? Thanks.

@metalwolf
Copy link
Author

@metalwolf metalwolf commented Mar 12, 2021

Sorry, my mistake using zip on unix O_o
Correct version is here:

test.zip

@cherrymui
Copy link
Contributor

@cherrymui cherrymui commented Mar 13, 2021

Thanks. I can reproduce the problem. I think I understand the cause now. Will work on a fix.

@cherrymui cherrymui changed the title go 1.16 plugin does not initialize global variables correctly when not used directly cmd/link: go 1.16 plugin does not initialize global variables correctly when not used directly Mar 13, 2021
@metalwolf
Copy link
Author

@metalwolf metalwolf commented Mar 13, 2021

Thanks. I already have a simple workaround, I just declare the global variable

var Containers map[string]*Container // without assignation

and I assign it into the init() function.

func init() {
Containers = &map[string]*Container{}
}

Works like a charm.

  • Phil
@cherrymui cherrymui added this to the Go1.17 milestone Mar 15, 2021
@cherrymui
Copy link
Contributor

@cherrymui cherrymui commented Mar 15, 2021

@gopherbot please backport this to Go 1.16. This is a mis-compilation bug in Go 1.16. Thanks.

@gopherbot
Copy link

@gopherbot gopherbot commented Mar 15, 2021

Change https://golang.org/cl/301793 mentions this issue: cmd/compile, cmd/link: dynamically export writable static tmps

@gopherbot
Copy link

@gopherbot gopherbot commented Mar 15, 2021

Backport issue(s) opened: #45030 (for 1.16).

Remember to create the cherry-pick CL(s) as soon as the patch is submitted to master, according to https://golang.org/wiki/MinorReleases.

@gopherbot
Copy link

@gopherbot gopherbot commented Mar 16, 2021

Change https://golang.org/cl/302449 mentions this issue: [release-branch.go1.16] cmd/compile, cmd/link: dynamically export writable static tmps

gopherbot pushed a commit that referenced this issue Mar 25, 2021
…table static tmps

Static tmps are private to a package, but with plugins a package
can be shared among multiple DSOs. They need to have a consistent
view of the static tmps, especially for writable ones. So export
them. (Read-only static tmps have the same values anyway, so it
doesn't matter. Also Mach-O doesn't support dynamically exporting
read-only symbols anyway.)

Updates #44956.
Fixes #45030.

Change-Id: I921e25b7ab73cd5d5347800eccdb7931e3448779
Reviewed-on: https://go-review.googlesource.com/c/go/+/301793
Trust: Cherry Zhang <cherryyz@google.com>
Run-TryBot: Cherry Zhang <cherryyz@google.com>
TryBot-Result: Go Bot <gobot@golang.org>
Reviewed-by: Than McIntosh <thanm@google.com>
(cherry picked from commit de012bc095359e1b552d4ea6fb6b2995f3ab04f5)
Reviewed-on: https://go-review.googlesource.com/c/go/+/302449
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
Linked pull requests

Successfully merging a pull request may close this issue.

None yet
5 participants
@metalwolf @gopherbot @seankhliao @cherrymui and others