go-debug icon indicating copy to clipboard operation
go-debug copied to clipboard

debug process not terminated/killed when hitting stop button + crash

Open fakecora opened this issue 9 years ago • 5 comments

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.

fakecora avatar Apr 28 '16 07:04 fakecora

Can you please create a minimal code example to reproduce this problem. Delve latest = ??? – please run dlv version Thanks!

lloiser avatar Apr 28 '16 08:04 lloiser

Added delve version, i'm fetching delve with go get on a daily base. Minimal code snippet will follow.

fakecora avatar Apr 28 '16 09:04 fakecora

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
    }
}

fakecora avatar Apr 28 '16 09:04 fakecora

great, I will try that later!

lloiser avatar Apr 28 '16 09:04 lloiser

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.

fakecora avatar Apr 29 '16 07:04 fakecora