goroutine 87 [IO wait]:
net.runtime_pollWait(0x2aaaaaab02a8, 0x72, 0xc82000a1a0)
/usr/local/go/src/runtime/netpoll.go:157 +0x60
net.(_pollDesc).Wait(0xc820161950, 0x72, 0x0, 0x0)
/usr/local/go/src/net/fd_poll_runtime.go:73 +0x3a
net.(_pollDesc).WaitRead(0xc820161950, 0x0, 0x0)
/usr/local/go/src/net/fd_poll_runtime.go:78 +0x36
net.(_netFD).Read(0xc8201618f0, 0xc92b57e000, 0x1000, 0x1000, 0x0, 0x2aaaaaaab050, 0xc82000a1a0)
/usr/local/go/src/net/fd_unix.go:232 +0x23a
net.(_conn).Read(0xc820035270, 0xc92b57e000, 0x1000, 0x1000, 0x0, 0x0, 0x0)
/usr/local/go/src/net/net.go:172 +0xe4
bufio.(_Reader).fill(0xc92b58b4a0)
/usr/local/go/src/bufio/bufio.go:97 +0x1e9
bufio.(_Reader).ReadSlice(0xc92b58b4a0, 0xc92b57e10a, 0x0, 0x0, 0x0, 0x0, 0x0)
/usr/local/go/src/bufio/bufio.go:328 +0x21a
bufio.(_Reader).ReadBytes(0xc92b58b4a0, 0xa, 0x0, 0x0, 0x0, 0x0, 0x0)
/usr/local/go/src/bufio/bufio.go:406 +0xa9
github.com/guotie/stomp.(_Reader).readLine(0xc820035278, 0x0, 0x0, 0x0, 0x0, 0x0)
/root/go/src/github.com/guotie/stomp/reader.go:135 +0x4e
github.com/guotie/stomp.(*Reader).Read(0xc820035278, 0xc92b58b7a0, 0x0, 0x0)
/root/go/src/github.com/guotie/stomp/reader.go:43 +0x45
github.com/guotie/stomp.readLoop(0xc820161a40, 0xc820035278)
/root/go/src/github.com/guotie/stomp/conn.go:250 +0x51
created by github.com/guotie/stomp.Connect
/root/go/src/github.com/guotie/stomp/conn.go:208 +0xd3e

What program are you running? What operating system? What version of Go? Is this easy to reproduce?

Are you sure this is a bug? If there is no network activity, then it is normal for this goroutine to wait.

OS: Linux; CentOS 6.4 x64
Go: 1.5.1
This is not easy to reproduce.

I use stomp to connect activeMQ, I'm sure the network is Ok and there should be data to send/recv, but the program hangs.

I use the net lib is always ok, but the stomp lib has hangs several times, I'm not sure if it is a golang's bug, but the stack shows it hangs at golang libary.

stomp: https://github.com/guotie/stomp

In order to fix any possible bug, we need more information. It is entirely normal for a goroutine reading from a descriptor to hang at that point waiting for more data on the socket.

For example, please set the environment variable GOTRACEBACK=2 and show us the entire stack dump of the program when it is hanging. It might also help to see the output of strace -f for a few minutes before the hang.

I reviewed activemq call stack, I think this should be activemq bug.