When the DSPDebugTarget receives output before a process was started, it creates a dummy process so that it can write the output to a console. When the debugger reports another process later on, the direct reference to this dummy process (DSPDebugTarget.process) is overwritten. Later on, when terminate is called on DSPDebugTarget, it only tries to terminate the last reported process, leaving the dummy process alive.
I noticed that this happens when debugging Python with debugpy, which sends telemetry output before starting a process.
For my specific case it would be enough to defer creation of a dummy process until we actually have something to write to the console, so something that isn't telemetry data.
When the DSPDebugTarget receives output before a process was started, it creates a dummy process so that it can write the output to a console. When the debugger reports another process later on, the direct reference to this dummy process (DSPDebugTarget.process) is overwritten. Later on, when terminate is called on DSPDebugTarget, it only tries to terminate the last reported process, leaving the dummy process alive.
I noticed that this happens when debugging Python with debugpy, which sends telemetry output before starting a process. For my specific case it would be enough to defer creation of a dummy process until we actually have something to write to the console, so something that isn't telemetry data.
Steps to reproduce:
print("foo")
-m debugpy.adapter
{"request": "launch", "program": "path/to/your/test.py"}
A workaround is to manually terminate the dummy process via the debug view, which allows to cleanup the launch