debug process not terminated/killed when hitting stop button + crash
Hi there,
i got the following issue: When debugging a server application that runs in an infinite for loop or within a waitgroup. Hitting the stop button does not kill the ./debug process which keeps the application running. This occured in a non deterministic way, sometimes it happened, sometimes not. This wasn't much of a problem since i was able to kill the debug process manually. It somehow got better during the previous update of go-debug.
But it got worse after installing the recent update, when i hit the stop button, sometimes an additional debug process ist launched, and when i kill them manually, atom stops responding and needs to be restartet, when i hit the "Debug"- Button again.
I'm using: Xubuntu 15.10 atom 1.7.2 go-debug 0.1.11 delve 0.11.0-alpha
P.S: Thank you very much for the work on go-debug besides go-plus it has become one of the packages i don't want to miss when working on go code with atom.
Can you please create a minimal code example to reproduce this problem.
Delve latest = ??? – please run dlv version
Thanks!
Added delve version, i'm fetching delve with go get on a daily base. Minimal code snippet will follow.
Allthough the following code snippet does not reprodcue the atom crash, it illustrates how the "./debug"-Task/Process is not killed/terminated. The "dlv=..." process shuts down, but "./debug" still remains, preventing the app from beeing debugged again because port 8015 is blocked.
package main
import (
"fmt"
"net"
"sync"
)
func main() {
var waitGroup sync.WaitGroup
defer waitGroup.Done()
waitGroup.Add(1)
fmt.Println("Launching Server..")
messageListener, _ := net.Listen("tcp", ":8015")
defer messageListener.Close()
go waitForMessage(messageListener)
waitGroup.Wait()
}
func waitForMessage(listener net.Listener) {
for {
//Wait for message
}
}
great, I will try that later!
The crashes might have come from the debug file which is created when hitting the debug tab, after deleting it the crashes didn't occur anymore. But the process problem still remains.