cmd/link, runtime: additab can be called twice for the same itab, leading to hangs

[mwhudson]

Please answer these questions before submitting your issue. Thanks!

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

tip, and 1.7 (but not 1.6)

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

linux/amd64, Ubuntu 16.04

What did you do?

(master)mwhudson@aeglos:/opt/opensource/go/src$ go install -v -buildmode=shared std
(master)mwhudson@aeglos:/opt/opensource/go/src$ cat /opt/opensource/go-test-cases/itabfun.go
package main

import (
    "os"
    "reflect"
    "runtime/debug"
    "syscall"
)

func main() {
    reflect.TypeOf(os.Stdout).Elem()

    fd, err := syscall.Open("/dev/null", os.O_WRONLY, 0644)
    if err == nil {
        debug.WriteHeapDump(uintptr(fd))
    }
}
(master)mwhudson@aeglos:/opt/opensource/go/src$ go run -linkshared /opt/opensource/go-test-cases/newrand.go

What did you expect to see?

The program complete quickly.

What did you see instead?

It hangs.

What is going on here is that the itab for the conversion of _reflect.rtype to reflect.Type, go.itab._reflect.rtype,reflect.Type , ends up in the itablinks of the moduledata for both libstd.so and the executable. As go.itab.*reflect.rtype,reflect.Type is a global symbol, the dynamic linker puts a pointer to the data in the executable into both itablinks. This means that additab gets called twice for the very same itab, which means that it ends up with its .link member pointing at itself. Anything that then traverses the itab linked list (like WriteHeapDump, but also just unlucky calls to getitab) ends up looping forever.

[mwhudson]

A simple fix is to make the go.itab.* symbols local. This will mean you'll get functionally identical itabs floating around, but not actually identical ones, which I think is safe. We'll see what the trybots think in a moment anyway.

Also paging @crawshaw

[crawshaw]

That does sound like an easy fix that should work.

[gopherbot]

CL https://golang.org/cl/32131 mentions this issue.