Logo Questions Linux Laravel Mysql Ubuntu Git Menu
 

How do I attach VS Code's Python debugger to a running process?

I'm using Jayamanne's Python version 0.7.0 running on VS Code. The documentation for attaching the debugger to a running process requires adding extra code and configuring ports and addresses. I figure there must be a simpler way by simply selecting or specifying a process name or id.

Apparently, VS Code is capable of it based on the Node.JS documentation and demo. The Python interpreter is also capable of it, since it is how I normally debug applications on Visual Studio 2017.

How do I configure VS Code Python to attach to a process by name or id? Is this possible? If not, why doesn't the documentation say it explicitly?

like image 278
ATL_DEV Avatar asked Sep 05 '17 18:09

ATL_DEV


1 Answers

There's no "easy" way. Follow the documentation you mentioned about "adding extra code and configuring ports and addresses".

You can only "attach" a C debugger to any process because Windows Debugging API has this functionality and provides all the necessary machinery working behind the scenes to make this seemingly easy operation possible (stopping the target process with OS means, creating a helper thread in it, manipulating its memory (incl. replacing machine code with int 3 to set a breakpoint) -- while Visual Stidio uses the source code and PDB files to parse the memory data into C- or C++-level constructs).

This isn't so for Python: while you can likewise break into the process at C level and manipulate an interpreter instance from the helper thread with the C API if you somehow get its address, there's no way provided in that API to make it break from the existing code passed to it and start executing your instructions instead while still being able to access the existing code.

pdb gets you into a debugging session via the "existing code": its sets the sys.settrace callback that the interpreter calls at certain moments to be able to bring up its console at breakpoints and/or wraps your program with itself and catches exceptions.

The debugger you're describing acts the same: only instead of bringing up a console prompt, its machinery acts as a server, accepting commands from a connected IDE client via a socket.

like image 176
ivan_pozdeev Avatar answered Oct 18 '22 15:10

ivan_pozdeev