-
Notifications
You must be signed in to change notification settings - Fork 646
Delete binary files created by delve after closing the debug session #1345
Comments
From @firelizzard18 on June 20, 2017 7:59 |
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). |
This modification works with PR microsoft#1379, RE microsoft#1345, to enable the removal of the debug binary when pressing the stop button.
Having 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
Better to replace the mess of ineffective code in your terminateProcess.sh with something that actually works, such as |
can I config the "debug" file path? for example I want delve create the big debug file in my TEMP directory |
I just installed the latest version of VSCode, I guess I'll |
@ramya-rao-a Are there any updates related to this issue? |
@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. |
@ramya-rao-a I tried but failed... or something wrong? in my package.json, i modified the path: "output": { but the DEBUG file still generate in path same as the .go file |
Any updates on this? Been running into this and was wondering if it is in the pipeline for July or August. |
I finally have an update! Turns out there is a command called
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 |
@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. |
@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 |
The fix for this issue is now out in the latest update (0.6.85) to the Go extension. |
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. |
@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 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). |
My executable IS NOT NAMED |
Just to be on the same page, are you referring to the
The You can also run the
Can you give an example that can elaborate this? |
I hope this explains it well Each configuration inside launch.json contains 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). 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. It's a bit annoying but it seems that I'll have to find a different workflow now. |
You could set up a build task that will run |
From @firelizzard18 on June 20, 2017 7:56
Steps to Reproduce:
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, youquit
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
The text was updated successfully, but these errors were encountered: