-
Notifications
You must be signed in to change notification settings - Fork 131
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Debugging through poetry drops subprocess #865
Comments
The short story is that Poetry uses Fixing this would require two things. First, pydevd should treat |
@int19h well, if we just make part 2 (make sure that code for auto-killing child processes handles this case properly, treating the child as the new root), that'd already be enough, no? Part 1 is probably more of a bonus to have an early exit message without the 6-second timeout, but if part 2 is done this shouldn't really be a problem in practice (right now I think that if we do that it'll just stop sooner without any delay, so, it wouldn't be good -- we'd probably need a special message saying that this is about to exit but another one will connect soon if we do want to implement that part, but I'm not sure it's worth it...). |
Yes, you're right, it would treat the entire multiproc session as over if the parent process exits before the child gets a chance to connect. And synchronizing that across processes would be very tricky to do right. But it should still work if we just let the process time out. Ironically, the timeout will also work as a workaround for #43 until it's fixed. |
The fix for this is probably on the connection management on the debugpy side. The caveat is:
I think a custom message should be relatively straightforward to send. The tricky part here is that since the process will be soon replaced we need to make sure that the message is read by debugpy prior to that -- we can do a request/response message which expects a confirmation so that pydevd sends it and waits for the acknowledgement before calling Maybe something as |
That would also make pydevd impossible to use directly by DAP clients that wouldn't know about this custom message. I think an event is sufficient, though (maybe even just a custom attribute in "exited"?). Even if the process exits immediately after sending it, so long as it's not buffered on pydevd side, the socket on debugpy side will have the packet, and won't report itself as closed until that data is read. So debugpy will see the message first before noticing disconnect, and has a chance to set the "new process is coming" flag. |
I think that the pydevd side doesn't really send an Given that, I think a custom event to note that the process will be replaced seems reasonable -- maybe a |
Yup, in general it can't reliably report exiting from inside the process. But this is one codepath where it's known that the process is, in fact, about to exit for sure, so I think it would be appropriate to use it here. For a client that doesn't support multiproc and uses pydevd directly, it would also serve as an indication of graceful process termination. OTOH |
Ok, how about an
then? |
Sounds good! |
There's still additional work to do - that particular change was adding the necessary infrastructure, but it still has to be wired up properly in debugpy. This issue remains open to track that work. |
Hello together, |
Handle "exited" { "pydevdReason": "processReplaced" } appropriately.
Handle "exited" { "pydevdReason": "processReplaced" } appropriately. Add test for os.exec() in-place.
Handle "exited" { "pydevdReason": "processReplaced" } appropriately. Add test for os.exec() in-place process replacement.
Handle "exited" { "pydevdReason": "processReplaced" } appropriately. Add test for os.exec() in-place process replacement.
I see this issue is fixed. So is it included in latest version of vs code? |
The fix is in debugpy 1.63, which shipped in vscode-python for some time now. Are you still seeing the issue? |
Environment data
Actual behavior
I have a
click
application (https://click.palletsprojects.com/en/8.0.x/) that is configured to run as apoetry
script. I have alaunch.json
config that can successfully launch the script, accept the arguments, and hit breakpoints that I set inside of the click functions.The issue is that the debugger detaches after 6 seconds no matter if breakpoints are set, the code is allow to run uninterrupted, using different arguments to trigger a different function, etc.
The call stack is showing the CLI file and the functions I break at to be inside a subprocess, and I have
subprocess
set totrue
, but I am wondering if this is part of the issue.I have reviewed this ticket and would expect this to work fairly similarly.
Expected behavior
The debugger would launch and allow stepping, etc, as usual.
Steps to reproduce:
click
file (below is using the example from their hello world)poetry
project with a script pointed to a python file usingclick
launch.json
config that can runpoetry
The text was updated successfully, but these errors were encountered: