Wingo-cmd can run into deadlocks

[vendion]

I'm using the wingo-cmd tool to pipe information like the active workspace and clients on that workspace into Lemonbar. This information is currently being polled every second, and that seems to be causing a deadlock.

fatal error: all goroutines are asleep - deadlock!

goroutine 1 [IO wait]:
net.(*pollDesc).Wait(0xc2080c6990, 0x72, 0x0, 0x0)
        /usr/local/go/src/net/fd_poll_runtime.go:84 +0x47
net.(*pollDesc).WaitRead(0xc2080c6990, 0x0, 0x0)
        /usr/local/go/src/net/fd_poll_runtime.go:89 +0x43
net.(*netFD).Read(0xc2080c6930, 0xc20800f000, 0x1000, 0x1000, 0x0, 0x7fcf54b05bc8, 0xc208088d50)
        /usr/local/go/src/net/fd_unix.go:242 +0x40f
net.(*conn).Read(0xc20804e310, 0xc20800f000, 0x1000, 0x1000, 0x0, 0x0, 0x0)
        /usr/local/go/src/net/net.go:121 +0xdc
bufio.(*Reader).fill(0xc20805a360)
        /usr/local/go/src/bufio/bufio.go:97 +0x1ce
bufio.(*Reader).ReadSlice(0xc20805a360, 0x1000, 0x0, 0x0, 0x0, 0x0, 0x0)
        /usr/local/go/src/bufio/bufio.go:295 +0x257
bufio.(*Reader).ReadBytes(0xc20805a360, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0)
        /usr/local/go/src/bufio/bufio.go:374 +0xd2
bufio.(*Reader).ReadString(0xc20805a360, 0xc20804e300, 0x0, 0x0, 0x0, 0x0)
        /usr/local/go/src/bufio/bufio.go:414 +0x58
main.main()
        /home/vendion/gocode/src/github.com/BurntSushi/wingo/wingo-cmd/main.go:77 +0x46f

The way this is getting polled is with the following script

#!/usr/bin/env zsh

cmd=$(which "wingo-cmd")

Workspace() {
  WorkSpace=$(${cmd} GetWorkspace)
  echo "Workspace: ${WorkSpace}"
}

GetClientList() {
  list=("${@f)$(${cmd} 'GetClientList (GetWorkspace)')}")
  output=""
  for item in ${list}; do
    name=$(${cmd} "GetClientName ${item}")
    output+=" ${name} |"
  done
  echo "Clients:${output}"
}

while true; do
  echo "%{l}$(Workspace) %{c}$(GetClientList)"
  sleep 1;
done

While that script works and returns the information, left running long enough the wingo-cmd start having issues.

This was tested on Go 1.4.2 linux/amd64 running Wingo and wingo-cmd from d7c36494edf2b38cdcbd705ba85e88dea2d19f9b

[BurntSushi]

Hmm, I have no idea what could be causing that. There's nothing fancy in wingo-cmd that could be causing a deadlock. Could you paste the wingo logs at the time that this occurs?

[vendion]

Sure, it may be a couple of days before I can get them to you.

On Tue, Jun 23, 2015, 7:40 PM Andrew Gallant notifications@github.com wrote:

Hmm, I have no idea what could be causing that. There's nothing fancy in wingo-cmd that could be causing a deadlock. Could you paste the wingo logs at the time that this occurs?

— Reply to this email directly or view it on GitHub https://github.com/BurntSushi/wingo/issues/123#issuecomment-114675095.

[vendion]

Okay now that I have net and time to mess with this again, here is wingo's logs with the logging level set to 4. I was guessing that would be the most helpful in this case.

http://sprunge.us/afOU

When wingo-cmd complains about deadlocks I only see this in wingo's logs

WINGO LOTS: ipc.go:83: Running command from IPC: 'GetClientList (GetWorkspace)'.
WINGO LOTS: ipc.go:83: Running command from IPC: 'GetClientName 39845891'.
WINGO LOTS: ipc.go:83: Running command from IPC: 'GetWorkspace'.
WINGO LOTS: ipc.go:83: Running command from IPC: 'GetClientList (GetWorkspace)'.
WINGO LOTS: ipc.go:83: Running command from IPC: 'GetClientName 39845891'.
WINGO LOTS: ipc.go:83: Running command from IPC: 'GetWorkspace'.
WINGO LOTS: ipc.go:83: Running command from IPC: 'GetClientList (GetWorkspace)'.
WINGO LOTS: ipc.go:83: Running command from IPC: 'GetClientName 39845891'.
WINGO LOTS: ipc.go:83: Running command from IPC: 'GetWorkspace'.
WINGO LOTS: ipc.go:83: Running command from IPC: 'GetClientList (GetWorkspace)'.
WINGO LOTS: ipc.go:83: Running command from IPC: 'GetClientName 39845891'.
WINGO LOTS: ipc.go:83: Running command from IPC: 'GetWorkspace'.
WINGO LOTS: ipc.go:83: Running command from IPC: 'GetClientList (GetWorkspace)'.
WINGO LOTS: ipc.go:83: Running command from IPC: 'GetClientName 39845891'.
WINGO WARNING: ipc.go:78: Error reading command '': read unix @: connection reset by peer

This makes it sound like it is a socket issue, such as hitting a connection limit or something. I don't see how though because this is currently only being polled one a second (maybe a bit overkill on my part) and in you're wingo-cmd example you show it polling client information every 500 milliseconds.