runtime: deadlock due to blocked glibc-internal signals

[hlandau]

The following code demonstrates the bug. The expected behaviour is that the program exits. Instead, the program hangs forever.

I did not experience these issues with Go 1.4; I suspect it is a result of the changes introduced in #9400, involving SIGSETXID.

go version go1.5 linux/amd64
Linux andover 4.1.2-2-ARCH #1 SMP PREEMPT Wed Jul 15 08:30:32 UTC 2015 x86_64 GNU/Linux

• The deadlock occurs regardless of whether you run the program as root, as setxid is attempted on all threads even if they all ultimately fail.
• Tested to occur with at least GOMAXPROCS=1 and GOMAXPROCS=8.

package main

import (
    "fmt"
    "os"
    "os/signal"
    "syscall"
)

/*
#define _GNU_SOURCE
#include <unistd.h>
*/
import "C"

func main() {
    signal.Notify(make(chan os.Signal, 10), syscall.SIGINT)
    fmt.Printf("rv: %v\n", C.setresgid(99, 99, 99))
}

[gopherbot]

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

[hlandau]

FYI, this is causing some quite serious issues. The Go1.5.1 milestone is maybe more appropriate?

[gopherbot]

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

[rsc]

A report from golang-dev says this still happens in go test -race mode:

From: Mark Pulford [email protected]
Date: Mon, Nov 23, 2015 at 7:21 PM
Subject: [golang-dev] Re: almost Go 1.5.2 in release-branch.go1.5
To: golang-dev [email protected]

I've just noticed that the Setgid test updated in rev a897684 fails under the race detector. The previous rev builds and tests cleanly.

$ set | grep ^GO
GO15VENDOREXPERIMENT=
GOARCH=amd64
GOBIN=
GOEXE=
GOGCCFLAGS='-fPIC -m64 -pthread -fmessage-length=0'
GOHOSTARCH=amd64
GOHOSTOS=linux
GOOS=linux
GORACE=
GOROOT=/home/mark/go
GOTOOLDIR=/home/mark/go/pkg/tool/linux_amd64
$ which go
~/go/bin/go

$ go test -run Setgid
PASS
ok      _/home/mark/go/misc/cgo/test    0.002s

$ go test -race -run Setgid
--- FAIL: TestSetgid (5.00s)
    setgid_linux.go:47: setgid hung after signal.Notify
FAIL
exit status 1
FAIL    _/home/mark/go/misc/cgo/test    5.007s

I haven't investigated further.

[ianlancetaylor]

I can not recreate the problem using -race.

[rsc]

Mark reports that he was running stale binaries.