Hang after timeout in timeoutWait

[ebfe]

After the timeout condition in proctl.timeoutWait is triggered, one of the next
next/step/continue commands will hang with dlv blocked in a wait syscall. I
believe the problem is that in the timeout case timeoutWait leaves a goroutine
running that is still executing a wait syscall. Now we have 2 goroutines which
race for the next SIGTRAP and if the abandoned timeoutWait goroutine
wins dlv hangs.

repo:

$ cat sleep.go
package main

import (
    "syscall"
)

func main() {
    ts := syscall.Timespec{ Sec: 3 }
    syscall.Nanosleep(&ts,  nil)
}


$ (echo -e "break syscall.Nanosleep\ncontinue"; yes step) | dlv -run

[ebfe]

Apparently there is a second failure mode where it doesn't hang completly, but every step command takes ~2sec (= timeoutWait timeout).

[derekparker]

Yeah, that timeoutWait is a bit of a crutch to handle a thread that can go from procfs reporting a trace stop, then a single step is requested, and that thread resumes a scheduler induced sleep - causing Delve to remain blocked in a wait for that thread.

I'm thinking through some ideas on how to better handle this situation, and that will fix the second failure mode, and should eliminate the race that you're describing. There is a small race in timeoutWait if an actual pid is provided where a SIGSTOP and SIGTRAP are racing and the wait executed by the goroutines gets the SIGTRAP and ignores it.

Also, there is a bug there where if the pid is -1 (to wait on all threads) and the timeout condition is met, a goroutine will be left indefinitely in a blocking wait. That is definitely an issue, but currently no callers of timeoutWait are passing -1 as the pid.

[derekparker]

Can you test and confirm this is no longer an issue. Just pushed some fixes up to master that should resolve this issue, and possibly #23 as well. If these issues seem to be fixed please close out the issue.

[ebfe]

Seems fixed as of afa3a9c