cmd/link: incorrect GC bitmap when global's type is in another shared object

[aclements]

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

$ go version
go version go1.14 linux/amd64

Also reproduced on master and as far back at Go 1.10.

Does this issue reproduce with the latest release?

Yes.

What did you do?

When linking in shared mode, if the type of a global variable is imported from a package in a different shared object, the global variable is marked as containing no pointers, which can cause the garbage collector to free reachable memory.

Here's an example from @cherrymui:

p.go

package p

type T [10]*int

main.go

package main

import "p"
import "runtime"

var x p.T
var y [10]*uint

func main() {
	for i := range x {
		x[i] = new(int)
		*x[i] = 12345
	}
	runtime.GC()
	runtime.GC()
	runtime.GC()
	for i := range y {
		y[i] = new(uint)
		*y[i] = 54321
	}
	runtime.GC()
	runtime.GC()
	runtime.GC()
	for i := range x {
		println(x[i], *x[i], y[i], *y[i])
	}
}

$ GOPATH=/tmp go install -buildmode=shared runtime sync/atomic
$ GOPATH=/tmp go install -buildmode=shared -linkshared p
$ GOPATH=/tmp go build -linkshared main
$ ./main
0xc00004a080 54321 0xc00004a080 54321
0xc00004a088 54321 0xc00004a088 54321
0xc00004a090 54321 0xc00004a090 54321
0xc00004a098 54321 0xc00004a098 54321
0xc00004a0a0 54321 0xc00004a0a0 54321
0xc00004a0a8 54321 0xc00004a0a8 54321
0xc00004a0b0 54321 0xc00004a0b0 54321
0xc00004a0b8 54321 0xc00004a0b8 54321
0xc00004a0c0 54321 0xc00004a0c0 54321
0xc00004a0c8 54321 0xc00004a0c8 54321

What did you expect to see?

In the example program, the garbage collector should not have freed the objects reachable from x, so it should have outputted:

0xc00004a080 12345 0xc00004a080 54321

What did you see instead?

The garbage collector incorrectly freed the objects reachable from x because its type was declared in a package in a different shared object.

/cc @cherrymui @jeremyfaller @thanm

[aclements]

This happens when the linker is building the gcprog for the globals. It calls decodetypeGcmask (or decodetypeGcprog) for the global's type. Since the type is declared in another shared object, it has symbol type sym.SDYNIMPORT, so decodetypeGcmask attempts to read it out of the right section in the shared object. However, the shared object has already been closed, so sect.ReadAt returns a "file already closed error". decodetypeGcmask ignores this error and simply returns the freshly-allocated, zeroed bitmap, indicating that the type has no pointers.

There's a secondary issue on ARM64 on master where decodetypeGcprogShlib returns 0, which causes findShlibSection to return the NULL section (which has address 0 and length 0), causing decodetypeGcmask to look in the wrong section, in addition to trying to read from a closed file.

[aclements]

For the secondary issue, CL 215997 made decodetypeGcprogShlib return 0 on ARM64, where previously it would return the addend of the relocation on the gcdata field (these relocations were collected by ldshlibsyms). However, while returning 0 is definitely wrong, we no longer need any special case for this on ARM64 because this addend now gets applied in place in the shared object, meaning the contents of the gcdata field are already the correct pointer on ARM64, just like on all the other platforms.

[gopherbot]

Change https://golang.org/cl/240462 mentions this issue: cmd/link: fix GC data reading from shared library

[networkimprov]

Backport candidate?

[gopherbot]

Change https://golang.org/cl/240616 mentions this issue: Revert "cmd/link: fix GC data reading from shared library"

[aclements]

Change reverted because it broke ppc64le.

[aclements]

@gopherbot, please backport to Go 1.14 and 1.13.

[gopherbot]

Backport issue(s) opened: #39955 (for 1.14), #39956 (for 1.13).

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]

Change https://golang.org/cl/240621 mentions this issue: cmd/link: fix GC data reading from shared library (attempt 2)

[gopherbot]

Change https://golang.org/cl/240511 mentions this issue: [release-branch.go1.14] cmd/link: fix GC data reading from shared library (attempt 2)

[gopherbot]

Change https://golang.org/cl/241087 mentions this issue: cmd/oldlink: port bug fixes to old linker

[gopherbot]

Change https://golang.org/cl/241978 mentions this issue: [release-branch.go1.13] cmd/link: fix GC data reading from shared library (attempt 2)