`next` hangs

[go-delve]

`next` hangs

[ebfe]

Minimized the example too much. This one shows the same behaviour and makes it more obvious why next shouldn't hang.

package main

import "fmt"

func count(ch chan <- int) {
        x := 0
        for {
                ch <- x
                tmp := x
                tmp += 1
                x = tmp
        }
}

func main() {
        ch := make(chan int)
        go count(ch)
        for {
====>       x := <- ch
            fmt.Println(x) 
        }
}

[derekparker]

Hmm.. I have an idea why this may be happening. Thanks for the error reproducing code. I'll wrap a test around this and start working on a fix.

[derekparker]

Did not mean for the last push to close this -- reopening as it's occasionally still an issue.

[cam72cam]

@derekparker I think the issue is with how you are stepping forward threads that are currently blocked waiting for a resource. I have been working on a project (https://github.com/cam72cam/burrow) to create a ncurses interface for delve. Here is the output of program posted above.

https://gfycat.com/ImpoliteLastBushsqueaker#
The gify came out a bit funny, so here are the commands to replicate

:break main.main
:break fmt.Println
:continue
:continue
:continue
:continue
s (next key)
s (next key)
s (next key)

The continue runs to the next breakpoint and only the main thread's context changes there.
When you call Next() on all of the threads, the ones that I think are blocking/waiting (runtime.usleep) are forced forward which causes something to go wrong.

[derekparker]

@cam72cam that's definitely the issue, and was solved partly by a recent commit last night which enabled next to handle goroutine thread context switching a little better.

There are certainly issues where Delve can continue a thread (M) that is blocked waiting for a G - which can cause Delve to hang. I'm thinking through some solutions to this problem and I have some experimental fixes hanging around on another branch. There are some fun and interesting problems around how to coordinate threads in such a way that the scheduler thread on the traced process is still able to do its job.

[ebfe]

Seems fixed as of afa3a9c. Thanks