You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
Repository navigation
Process creation after debugging session not possible: teardown needed #2014
this does not work because subprocess was patched. Also not after teardown of the debugging session:
from debugpy._vendored.pydevd.pydevd import stoptrace
stoptrace() to continue running the process. Now, subprocess.popen() does not work any more at al.
.... still subprocess.Popen will not work
Expected behavior
subprocess.Popen() should work
Steps to reproduce:
After debugging started, the following won't work. Make sure NOT to issue
debugpy.configure(subProcess=False) in order to reproduce this:
SOLUTION
pydevd's patch_new_process_functions() patches _winapi.CreateProcess to intercept child process creation for subprocess debugging, but stoptrace() never unpatches it.
The effect is that you can't spawn processes after a debugging session is torn down and you want to resume your program without restart. The solution is a restoration on teardown:
from debugpy._vendored.pydevd.pydevd import stoptrace
stoptrace()
debugpy.server.api.listen.called = False # reset state so it can reconnect later
try:
import _winapi as _subprocess
except ImportError:
import _subprocess
if hasattr(_subprocess, 'original_CreateProcess'):
_subprocess.CreateProcess = _subprocess.original_CreateProcess
del _subprocess.original_CreateProcess
I think what you're suggesting is that if this code was done at detach:
stoptrace()
debugpy.server.api.listen.called=False# reset state so it can reconnect latertry:
import_winapias_subprocessexceptImportError:
import_subprocessifhasattr(_subprocess, 'original_CreateProcess'):
_subprocess.CreateProcess=_subprocess.original_CreateProcessdel_subprocess.original_CreateProcess
That's how I solved it. The debugger currently is 'throwaway' meaning you can initiate a debug process, do your debugging and after that disconnect or kill the debugged process but you can't initiate again with the debugger in the same process.
In my scenario, I like to have multiple connects/disconnects between debugger and debugee. That wouldn't work because no new adapter would spawn from the debugee after the first adapter was created, engaged and dismissed.
In my case, I like to have a debugger() statement in my Python code that initiates VS Code engagement so I made that too (node.js plugin in VSCode). Basically, python signals VS Code 'hey I have a debugger adapter ready' and VS Code listens on that signal channel, then when a signal is received, VS Code connects on initiative of the 'I want to be debugged' process. Nice for in an error handler. Just try/except/debugger(). Let a few processes run, VS fired up, and the first process to run into trouble automatically connects to VSCode.
Robert van Geel
From: Rich Chiodo ***@***.***>
Sent: Monday, 23 March 2026 17:06
To: microsoft/debugpy ***@***.***>
Cc: Lexcon ***@***.***>; Author ***@***.***>
Subject: Re: [microsoft/debugpy] Process creation after debugging session not possible: teardown needed (Issue #2014)
<https://avatars.githubusercontent.com/u/19672699?s=20&v=4> rchiodo left a comment (microsoft/debugpy#2014) <#2014 (comment)>
I think what you're suggesting is that if this code was done at detach:
stoptrace()
debugpy.server.api.listen.called = False # reset state so it can reconnect later
try:
import _winapi as _subprocess
except ImportError:
import _subprocess
if hasattr(_subprocess, 'original_CreateProcess'):
_subprocess.CreateProcess = _subprocess.original_CreateProcess
del _subprocess.original_CreateProcess
It would work?
—
Reply to this email directly, view it on GitHub <#2014?email_source=notifications&email_token=AA7G564ON2ZNSETZAYTHIOT4SFOHNA5CNFSNUABFM5UWIORPF5TWS5BNNB2WEL2JONZXKZKDN5WW2ZLOOQXTIMJRGE3TONBVHE3KM4TFMFZW63VGMF2XI2DPOKSWK5TFNZ2KYZTPN52GK4S7MNWGSY3L#issuecomment-4111774596> , or unsubscribe <https://github.com/notifications/unsubscribe-auth/AA7G56ZR6FGATQQZ5DDIKGL4SFOHNAVCNFSM6AAAAACW26TKPWVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHM2DCMJRG43TINJZGY> .
You are receiving this because you authored the thread. <https://github.com/notifications/beacon/AA7G566M42MFOO2EI4V3RBL4SFOHNBFCNFSM6AAAAACW26TKPWWGG33NNVSW45C7OR4XAZNMJFZXG5LFINXW23LFNZ2KUY3PNVWWK3TUL5UWJTXVCSZYJJTSMVQXG33OUZQXK5DIN5ZA.gif> Message ID: ***@***.*** ***@***.***> >
Activity
rchiodo commentedon Mar 23, 2026
I think what you're suggesting is that if this code was done at detach:
It would work?
Lexcon commentedon Mar 23, 2026