runtime: deadlock in runtime_pollWait #30957
Labels
FrozenDueToAge
NeedsInvestigation
Someone must examine and confirm this is a valid issue and not a duplicate of an existing one.
Milestone
Comments
ianlancetaylor
changed the title
ianlancetaylor
added
the
NeedsInvestigation
|
What is Can you share a complete program that demonstrates the problem? |
|
Hi Ian, As you can see from I will prepare a minimal working example, and will try to reproduce this on my workstation. |
|
@ianlancetaylor I believe I have made a code that has 100% reproducibility on my machine. Deadlock is instant. Code: package main
import (
"fmt"
"net"
"os"
"runtime"
"time"
)
var tty *os.File
func main() {
var err error
// Open TTY
tty, err = os.Open("/dev/tty")
if err != nil {
fmt.Println("Error opening TTY:", err.Error())
os.Exit(1)
}
defer tty.Close()
// Listen for incoming connections
l, err := net.Listen("tcp", "0.0.0.0:2019")
if err != nil {
fmt.Println("Error listening:", err.Error())
os.Exit(1)
}
fmt.Println("GOMAXPROCS =", runtime.GOMAXPROCS(0))
// Close the listener when the application closes
defer l.Close()
fmt.Println("Listening on port 2019")
// Listen for an incoming connection
for {
conn, err := l.Accept()
if err != nil {
fmt.Println("Error accepting:", err.Error())
os.Exit(1)
}
go connection_handler(conn)
}
}
func connection_handler(conn net.Conn) {
fmt.Println("Connection accepted:", conn.RemoteAddr())
// Close connection on completion
defer conn.Close()
// Use ticker to send data at fixed intervals
ticker := time.NewTicker(10 * time.Millisecond)
defer ticker.Stop()
// Connection loop
for {
// Read data
msg, err := read_tty(tty)
if err != nil {
if os.IsTimeout(err) {
continue
}
fmt.Println("Error preparing message:", err.Error())
break
}
// Send data
_, err = conn.Write([]byte(msg))
if err != nil {
break
}
fmt.Print(".")
// Wait for ticket trigger
<-ticker.C
}
// Done
fmt.Println("Connection closed:", conn.RemoteAddr())
}
func read_tty(f *os.File) ([]byte, error) {
// Set tiny read timeout
err := f.SetDeadline(time.Now().Add(time.Millisecond))
if err != nil {
return nil, err
}
// Read few bytes
data := make([]byte, 10)
_, err = f.Read(data)
if err != nil {
return nil, err
}
// Done
return data, nil
}Instructions: Terminal 1: $ go build
$ ./pollwait
GOMAXPROCS = 1
Listening on port 2019
Connection accepted: 127.0.0.1:37586Terminal 2: nc 127.0.0.1 2019This results to immediate deadlock. Killing application from terminal 3 with
GOARCH="amd64"
GOBIN=""
GOCACHE="/home/test/.cache/go-build"
GOEXE=""
GOFLAGS=""
GOHOSTARCH="amd64"
GOHOSTOS="linux"
GOOS="linux"
GOPATH="/home/test/go"
GOPROXY=""
GORACE=""
GOROOT="/usr/local/go"
GOTMPDIR=""
GOTOOLDIR="/usr/local/go/pkg/tool/linux_amd64"
GCCGO="gccgo"
CC="gcc"
CXX="g++"
CGO_ENABLED="1"
GOMOD=""
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 -fno-caret-diagnostics -Qunused-arguments -fmessage-length=0 -fdebug-prefix-map=/tmp/go-build981214745=/tmp/go-build -gno-record-gcc-switches" |
|
i have same problem. |
|
Thanks for the test case. The problem doesn't reproduce for me on amd64, and I'm trying to see if I can recreate it on ARM. In the meantime, can you run the Go program with |
|
That's weird. I have updated to latest 1.12.5 release and cannot reproduce the issue anymore. |
|
I don't know what change might have fixed the issue, but if we can't reproduce this I will close the issue. Please comment if you disagree. |
Sign up for free
to subscribe to this conversation on GitHub.
Already have an account?
Sign in.
What version of Go are you using (
go version)?Does this issue reproduce with the latest release?
Yes
What operating system and processor architecture are you using (
go env)?go envOutputWhat did you do?
Following function executes in a TCP connection handler. This code is triggered every 10ms by a ticker (
time.NewTicker(10 * time.Millisecond)).What did you expect to see?
No deadlock.
What did you see instead?
Deadlock. Hard to reproduce (~5 times in 2 days of spontaneous testing).
kill -3 <pid>gives following:The text was updated successfully, but these errors were encountered: