Delete binary files created by delve after closing the debug session

[ramya-rao-a]

From @firelizzard18 on June 20, 2017 7:56

• VSCode Version: Code 1.13.1 (379d2efb5539b09112c793d3d9a413017d736f89, 2017-06-14T18:13:05.928Z)
• OS Version: Darwin x64 16.6.0
• Extensions:

Extension	Author	Version
aurelia	AureliaEffect	0.3.4
vscode-npm-script	eg2	0.2.0
task-master	ianhoney	0.1.39
quicktask	lkytal	2.8.0
Go	lukehoban	0.6.62
debugger-for-chrome	msjsdiag	3.1.4

---

Steps to Reproduce:

1. Open a Golang project
2. Debug something
3. Stop debugging (via Stop, aka the red square or Shift+F5)

---

delve is the debugger for golang, or at least it's the one that the Go extension uses. When you debug something with delve, it creates a large binary file in the current directory. If you debug a main function (dlv debug), you get 'debug'. If you debug a test function (dlv test), you get 'debug.test'.

In normal delve usage, when you're done, you quit delve. Delve then deletes this file. Apparently VSCode gracelessly terminates (SIGKILL?) delve, which means the file sticks around.

Copied from original issue: microsoft/vscode#29089

[ramya-rao-a]

From @firelizzard18 on June 20, 2017 7:59

This may be a regression from #765 which fixed #438

[ramya-rao-a]

From @weinand on June 20, 2017 10:3

Yes, VS Code terminates debug adapters "gracelessly" (and we are planning to make this more graceful in the future).
But for now the VS Code Go debugger could 'quit' delve nicely when receiving a DisconnectRequest from VS Code. This is always the last request sent from VS Code to the debug adapter before killing the debug adapter. And VS Code kills the VS Code Go debugger only after it has received the response from the DisconnectRequest. So the debug adapter can delay the killing enough so that delve could do its cleanup.

[NexWeb]

Having kill -9 outside the for loop kills debug as well as debugserver and dlv.
This signal cannot be caught or ignored, and the receiving process cannot perform any clean-up upon receiving this signal.

Don't believe it? Place the following into a text file, save as listpids.sh, fire up vsCode, hit your breakpoint, run top, get the Code Helper PID, run sh listpids.sh XXX, where XXX is the PID you found. Then try running listpids.sh again with the echo $1 inside the for loop.

#!/bin/bash

terminateTree() {
	for cpid in $(/usr/bin/pgrep -P $1); do
		terminateTree $cpid	
done
echo $1	
}

for pid in $*; do
	terminateTree $pid
done

Better to replace the mess of ineffective code in your terminateProcess.sh with something that actually works, such as pkill debug.

[chuchiring]

can I config the "debug" file path?

for example I want delve create the big debug file in my TEMP directory

[ecbrodie]

I just installed the latest version of VSCode, vscode-go, go and delve onto my machine (Mac OS 10.13.4, also latest). I'm still running into this issue.

I guess I'll .gitignore the debug file, but is anyone else still running into this issue? Ideally this is cleaned up automatically. I'm not excited to have to run a looping cleanup script.

[NexWeb]

Better to replace the mess of ineffective code in your terminateProcess.sh with what actually works, pkill debug. WFM, for more than a year without issue. The only hassle is having to re-modify terminateProcess.sh after updates of the extension.

[mxschmitt]

@ramya-rao-a Are there any updates related to this issue?

[ramya-rao-a]

@chuchiring From Go 0.6.78 onwards, you can configure where the binary generated by delve is located. See https://github.com/Microsoft/vscode-go/wiki/Release-Notes#0678---3rd-april-2018

@mxschmitt Sorry, no updates yet. But will definitely get around to this in June.

[chuchiring]

@ramya-rao-a I tried but failed... or something wrong?

in my package.json, i modified the path:

"output": {
"type": "string",
"description": "Output path for the binary of delve",
"default": "r://"
},

but the DEBUG file still generate in path same as the .go file

[jadchaar]

Any updates on this? Been running into this and was wondering if it is in the pipeline for July or August.

[ramya-rao-a]

I finally have an update!

Turns out there is a command called Detach that can be called on the delve server which will result in the required clean up of the debug binary that gets generated. To get this fix before the next update to the Go extension (which will be either Friday or early next week), please follow the below:

• Download https://github.com/Microsoft/vscode-go/blob/master/Go-latest.vsix
• Run code --install-extension Go-latest.vsix
• If the above fails with Error: end of central directory record signature not found, then clone this repo and use the Go-latest.vsix file from the cloned repo
• Reload VS Code

I'd appreciate it if folks here can give the fix a try and share any feedback.

@chuchiring The change you need to do to provide an output path for the generated debug binary is in the launch.json file. Use the property output in your debug configuration. Please dont modify the package.json file.

[chuchiring]

@ramya-rao-a ok thank you, it worked after I created a launch.json and add my custom file path to the property "output"!, finally, almost half year.

[ramya-rao-a]

@NexWeb After looking into dlv apis, I found a command to detach gracefully that cleans up the debug binary that is created as well as kills all the processes spawned in the process. This means we no longer have to specifically kill any processes from our end.

I know your fix as worked flawlessly for you for more than a year. I would appreciate it if you could try the current fix. If you do decide to try it out, please follow the instructions in
#1345 (comment)

[ramya-rao-a]

The fix for this issue is now out in the latest update (0.6.85) to the Go extension.

[mvrhov]

I hate to be a nag, and I know that this was a regression fix, but some of us who came in late this fix is now a regression. IMO, the behavior as was before ws correct. every IDE that produces the executable leaves it in it's place.
The other thing is that now one to run the executable outside of the ide now must do a manual build. Also if the output dir & executable name are the same for the build script and the vscode debug the next run will remove the file.

[firelizzard18]

@mvrhov Do you normally want your executables to be named ‘debug’?

Every other IDE is designed for other languages. Go does things differently. For example, the convention of every other language is to put artifacts in their own folder. Go only generates one artifact (if you ignore the pkg folder) and it puts it in the current directory. Another example, the accepted convention for production builds is to use go install to install the artifact to the go bin folder, which you can add to your path. Not to mention that building go is stupid simple and stupid fast.

In summary, Go’s philosophy and tooling is radically different from essentially every other language, so it’s not a terribly valid comparison.

Plus VSCode isn’t an IDE in my book. A development environment, yes. But modular rather than ‘integrated’ (aka monolithic and bloated).

[mvrhov]

My executable IS NOT NAMED debug. I have the output set under the configurations where I properly name each one of them.

[ramya-rao-a]

@mvrhov

every IDE that produces the executable leaves it in it's place.

Just to be on the same page, are you referring to the debug binary created by delve during the debugging process or the executable created when you run go install?

The other thing is that now one to run the executable outside of the ide now must do a manual build

The debug binary created by delve was never meant to be run on its own. It is specifically for delve to use for debugging purposes. If you were to use delve from the terminal (dlv debug), you will see the same debug file being created for the duration of the debugging session. When you exit the debugging session, the file is deleted by delve.

You can also run the Go: Install Current Package command (which does nothing but go install on your pacakge) to get a binary under GOPATH/bin

the output dir & executable name are the same for the build script and the vscode debug the next run will remove the file.

Can you give an example that can elaborate this?

[mvrhov]

I hope this explains it well

Each configuration inside launch.json contains "output": "${workspaceRoot}/bin/<app_name>debug",", The above output contains same name/path that is later used in build.sh script (build.sh does a bit more than just go install). And this is the file that now gets deleted.

My workflow until now was.. Write some go code, press F5 / Shift+Ctrl+F5 to build it (sometimes build was all that's needed also having configuration for each and every combination of command line switches is not manageable, also the behavior for build/run in IDEs is usually the same command).
Switch to console and run the command with proper switches.

Also I don't need the full build e.g with packaging assets into the executable that the build.sh does when run on dev machine as it's a waste of time.
Switch to terminal to run the executable with proper switches. (However now the executable is gone) So I have to run build.sh to build it again and then run it.

It's a bit annoying but it seems that I'll have to find a different workflow now.

[firelizzard18]

You could set up a build task that will run go build ./your/exe/package, which you could then run with Ctrl+Shift+B or Cmd+Shift+B, followed by Return.