Skip to content
This repository has been archived by the owner on Jul 15, 2023. It is now read-only.

When hitting Stop during Debug, it does not always kill debug process #438

Closed
intdel opened this issue Aug 16, 2016 · 40 comments
Closed

When hitting Stop during Debug, it does not always kill debug process #438

intdel opened this issue Aug 16, 2016 · 40 comments
Assignees
Labels

Comments

@intdel
Copy link

intdel commented Aug 16, 2016

I am running a web server in Go (1.6) with visual studio code and the most recent plugin:

func main() {

    http.HandleFunc("/data", htmlHandler)

    err := http.ListenAndServe(":8080", nil)
    if err != nil {
        log.Fatal(err)
    }
    os.Exit(0)
}

When I hit the stop button on the small debug window, it does not kill the webserver, because after I hit F5 again I get:

2016/08/16 15:34:13 server.go:71: Using API v1
2016/08/16 15:34:13 debugger.go:61: launching process with args: [./debug]
API server listening at: 127.0.0.1:2345
2016/08/16 15:34:13 debugger.go:393: continuing
2016/08/16 15:34:13 listen tcp :8080: bind: address already in use

So I will have to look manually for the PID and kill it. Then it works again.

@lukehoban
Copy link
Contributor

What OS, and do you have a full precise repro? I tried a few times on Windows and OSX with the closest full example I could derive from the above and couldn't reproduce this.

Happy to reopen if you have more info to investigate.

@intdel
Copy link
Author

intdel commented Aug 22, 2016

Sure. I am using Debian Testing with Google Chrome Version 52.0.2743.116 (64-bit) and VS code Version 1.4.0:

lsb_release -a
No LSB modules are available.
Distributor ID: Debian
Description:    Debian GNU/Linux testing (stretch)
Release:    testing
Codename:   stretch

Here is an example code that I used to successfully verify the issue:
web.go:

package main

import "net/http"
import "fmt"
import "log"

func welcomeHandler(w http.ResponseWriter, r *http.Request) {

    fmt.Fprintln(w, "hello")
}

func main() {

    http.HandleFunc("/", welcomeHandler)

    err := http.ListenAndServe(":8080", nil)

    if err != nil {
        log.Fatal(err)
    }

}

launch.json:

{
    "version": "0.2.0",
    "configurations": [
        {
            "name": "Launch",
            "type": "go",
            "request": "launch",
            "mode": "debug",
            "remotePath": "",
            "port": 2345,
            "host": "127.0.0.1",
            "program": "${workspaceRoot}",
            "env": {},
            "args": [],
            "showLog": true
        }
    ]
}

Steps to reproduce:

  1. Press F5 to launch the debug process
  2. Open terminal and do pidof debug:
$ pidof debug                                                                                                                                                       
5441     

\3. Open browser and go to http://localhost:8080. You will see "hello
4. Hit the red stop button in VS Code
5. Refresh browser again and it's still hello
6. Pidof again:

$ pidof debug                                                                                                                                                       
5441    

\7. Hit F5 again and you will get error
:

2016/08/21 19:13:05 server.go:71: Using API v1
2016/08/21 19:13:05 debugger.go:61: launching process with args: [./debug]
API server listening at: 127.0.0.1:2345
2016/08/21 19:13:06 debugger.go:393: continuing
2016/08/21 19:13:06 listen tcp :8080: bind: address already in use

You can use pidof again and you will see that it is still the same process.

@lukehoban lukehoban reopened this Sep 6, 2016
@jaylittle
Copy link

jaylittle commented Sep 8, 2016

Can confirm this. Seeing this exact same behavior with go debugging using this vscode extension on Arch Linux.

@bsphere
Copy link

bsphere commented Sep 12, 2016

same behavior with Ubuntu 16.04 and vscode 1.5.1

@therox
Copy link

therox commented Sep 13, 2016

  • vscode 1.5.2, Ubuntu 16.04

@d10r
Copy link

d10r commented Oct 13, 2016

Same here. Ubuntu 14.04, vscode 1.6.0, vscode-go 0.6.44

@roblourens
Copy link
Member

I can repro this, and confirm that it works correctly with delve. So maybe we can do whatever delve does.

@Polarbear2121
Copy link

Hi,

I'm getting the same messages

2016/10/22 13:37:09 server.go:71: Using API v1
2016/10/22 13:37:09 debugger.go:61: launching process with args: [./debug]
API server listening at: 127.0.0.1:2345
2016/10/22 13:37:09 debugger.go:393: continuing

Is there a way to clear the messages?

Thank you

OSX 10.12
GO 1.7.3
GO Plug-in 0.6.45

@intdel
Copy link
Author

intdel commented Oct 23, 2016

@jferrer21 As far as I can see, your messages are not "errors" but rather informative. It would be an error if it had the line 2016/08/21 19:13:06 listen tcp :8080: bind: address already in use. Maybe you omitted it when pasting it?

Otherwise you can get rid of those messages by setting "showLog": true to "showLog": false in launch.json

@Polarbear2121
Copy link

I didn’t get the last line. Thank you for the info, about setting the showLog.

@nezorflame
Copy link
Contributor

nezorflame commented Nov 10, 2016

Getting the same behaviour on Mint 18 with the vscode 1.7.1 and go 1.7.3.
"debug" process is not being killed after Stop button is pressed.

@cgroves3
Copy link

same behavior with ubuntu 14.04.5 LTS and vscode 1.8.1

@TobiEiss
Copy link

TobiEiss commented Jan 3, 2017

Same here. Ubuntu 16.04, vscode 1.8.0, vscode-go 0.6.51

@esomore
Copy link

esomore commented Jan 7, 2017

Same here Ubuntu 16.04 vscode 1.8.0

@sysroad
Copy link

sysroad commented Feb 3, 2017

Same here Ubuntu 16.04 and VSCode 1.9.0 and Go Extension 0.6.53

roblourens added a commit that referenced this issue Feb 3, 2017
@ramya-rao-a
Copy link
Contributor

I can't repro the issue and so cannot test the fix. Can anyone on this thread volunteer to test this?
Steps:

  • Clone the repo https://github.com/Microsoft/vscode-go
  • cd into the repo
  • Get the branch with the fix roblou/killProcs
  • npm install
  • If you don't have the vsce tool, then npm install -g vsce
  • vsce package to get the vsix file for the extension
  • code --install-extension Go-0.6.53.vsix to install the extension from the six
  • now run vs code as you normally would

@intdel
Copy link
Author

intdel commented Feb 5, 2017

@ramya-rao-a I was trying out the steps you provided. However, at npm install I get:

npm ERR! 404 Not Found
npm ERR! 404 
npm ERR! 404 'types/fs-extra' is not in the npm registry.
npm ERR! 404 You should bug the author to publish it
npm ERR! 404 It was specified as a dependency of 'Go'
npm ERR! 404 
npm ERR! 404 Note that you can also install from a
npm ERR! 404 tarball, folder, or http url, or git url.

@ramya-rao-a
Copy link
Contributor

@intdel Am not sure why you are seeing that error, I am able to npm install successfully on a freshly cloned repo. What is your version of node and npm?

Nevertheless, you can comment the line for @types/fs-extra from package.json and continue. It is just a dev dependency, and since you will directly be packaging the code into a vsix, you wont need it

@intdel
Copy link
Author

intdel commented Feb 5, 2017

@ramya-rao-a Thanks. Now I am getting

 vsce package

/usr/local/lib/node_modules/vsce/node_modules/denodeify/index.js:40
                        return new Promise(promiseHandler);
                                   ^
ReferenceError: Promise is not defined
    at /usr/local/lib/node_modules/vsce/node_modules/denodeify/index.js:40:15
    at readManifest (/usr/local/lib/node_modules/vsce/out/package.js:359:20)
    at pack (/usr/local/lib/node_modules/vsce/out/package.js:523:12)
    at Object.packageCommand (/usr/local/lib/node_modules/vsce/out/package.js:532:12)
    at Command.<anonymous> (/usr/local/lib/node_modules/vsce/out/main.js:62:31)
    at Command.listener (/usr/local/lib/node_modules/vsce/node_modules/commander/index.js:301:8)
    at Command.emit (events.js:98:17)
    at Command.parseArgs (/usr/local/lib/node_modules/vsce/node_modules/commander/index.js:615:12)
    at Command.parse (/usr/local/lib/node_modules/vsce/node_modules/commander/index.js:458:21)
    at module.exports (/usr/local/lib/node_modules/vsce/out/main.js:110:13)

@ramya-rao-a
Copy link
Contributor

wow, can you share what version of node, npm and typescript you have?

@intdel
Copy link
Author

intdel commented Feb 6, 2017

npm version { http_parser: '1.0', node: '0.10.29', v8: '3.14.5.8', ares: '1.10.0', uv: '0.10.27', zlib: '1.2.8', modules: '11', openssl: '1.0.1k', npm: '1.4.21', Go: '0.6.53' }

node --version v0.10.29

typescript@2.1.5

In package.json I had to remove all of the devdependencies with "@types" otherwise I could not run npm install. Not sure if this is the reason.

I am running this on Debian Jessie.

@ramya-rao-a
Copy link
Contributor

Yay! Thanks @intdel !!

@YCF
Copy link

YCF commented Feb 18, 2017

Getting the same behaviour on Manjaro with the vscode 1.9.1 ,vscode-go 0.6.53 and go 1.8.
"debug" process is not being killed after Stop button is pressed.

@ramya-rao-a
Copy link
Contributor

@YCF Thanks for reporting, the fix will out in the next update of the Go extension early next week.

@cevn
Copy link

cevn commented Feb 28, 2017

Any update on this? It's pretty annoying to use the debugger on linux right now.

edit: I see you are preparing to release this update now haha. Sorry for my impatience.

@ramya-rao-a
Copy link
Contributor

Fixed in the latest update (0.6.54) to the Go extension.

@cevn This update was due for a while, sorry to keep you waiting :)

@YCF
Copy link

YCF commented Mar 1, 2017

0.6.54 this fix not worked.
"debug" process is not being killed after Stop button is pressed.

I binding hotkey F4-> "killall debug"

@roblourens
Copy link
Member

@YCF That would probably be a different issue. The debug process should have always been killed. This is for other processes spawned by the program.

Can you open a new issue and tell us your OS, vscode version, etc?

@kisPocok
Copy link

kisPocok commented Mar 3, 2017

"debug" process is not being killed after Stop button is pressed.

Exactly the same error here.

vscode 1.10.1
go extension 0.6.54
macOS 10.12.3

@YCF Could you send me the binding code?
{ "key": "f4", "command": "killall debug"} doesn't work ofc :) Thanks!

@YCF
Copy link

YCF commented Mar 4, 2017

@YCF
Copy link

YCF commented Mar 4, 2017

Fixed at go extension 0.6.55
@kisPocok have a try.

@hyacinthus
Copy link

ArchLinux still have this behavior.

@ramya-rao-a
Copy link
Contributor

@hyacinthus Can you share sample code and repro steps?

Are you saying that using the same code in other platforms in VS Code, you don't see the issue?

@hyacinthus
Copy link

Yes,I use Windows 10, Mac OS, and Archlinux in different places, but same project. Only Archlinux have this issue. I must kill dlv and debug process every time.

When I arrive my office next Monday , I'll create a simple demo to try if this behavior appears in every golang project.

@ramya-rao-a
Copy link
Contributor

@roblourens Can you think of any reason why this solution wouldn't work in just linux?

@roblourens
Copy link
Member

It should work. The code that kills the processes is

 terminateTree() {
  	for cpid in $(/usr/bin/pgrep -P $1); do
  		terminateTree $cpid
  	done
  	kill -9 $1 > /dev/null 2>&1
  }

I don't know if there's something particular about archlinux that would make this not work.

@hyacinthus
Copy link

@ramya-rao-a After the upgrade 1.13, it no longer appears this morning.
I will continue to focus on it.

@ramya-rao-a
Copy link
Contributor

Hello all,

We have revisited the fix to this issue by using the detach command from dlv instead of manually killing the processes from our end. I would appreciate it, if anyone here can give the fix a try. Please follow the below instructions to do so:

@microsoft microsoft unlocked this conversation Jul 20, 2018
@vscodebot vscodebot bot locked and limited conversation to collaborators Jul 23, 2018
@microsoft microsoft unlocked this conversation Aug 12, 2018
@vscodebot vscodebot bot locked and limited conversation to collaborators Aug 15, 2018
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
Projects
None yet
Development

No branches or pull requests