Skip to content
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

PTVSD Debugging after python process has exited. #1571

Closed
RaymonGulati1 opened this issue Jul 8, 2019 · 16 comments
Closed

PTVSD Debugging after python process has exited. #1571

RaymonGulati1 opened this issue Jul 8, 2019 · 16 comments

Comments

@RaymonGulati1
Copy link

@RaymonGulati1 RaymonGulati1 commented Jul 8, 2019

Environment data

  • PTVSD version: 4.2.10
  • OS and version: Windows 10
  • Python version (& distribution if applicable, e.g. Anaconda): 3.7
  • Using VS Code or Visual Studio: VS

Actual behavior

After a python script has finished executing, VS remains in debug mode

Expected behavior

After script has finished executing, VS should stop debugging.

Steps to reproduce:

  1. Run a python script without debugging and attach to debugger using TCP
  2. Let the python script run till the end
  3. After the script has finished executing, VS remains in debug mode

image

Related to #1553, but this is much easier to reproduce.

@karthiknadig
Copy link
Member

@karthiknadig karthiknadig commented Jul 8, 2019

Dupe #1553

@karthiknadig
Copy link
Member

@karthiknadig karthiknadig commented Jul 8, 2019

Reopening since this is a different context for the same issue.

@karthiknadig karthiknadig reopened this Jul 8, 2019
@karthiknadig karthiknadig added the Bug label Jul 8, 2019
@fabioz
Copy link
Collaborator

@fabioz fabioz commented Jul 8, 2019

I couldn't reproduce this with a plain launch and attaching from VSCode.

From the screenshot, it seems that there's an Press any key to continue..., so, it seems that the setting to wait for exit is turned on.

@RaymonGulati1 can you confirm if you have the setting to wait for exit turned on? (in Options > Python > Debugging there are settings to wait for exit when process exits abnormally or normally)

Do you reproduce it if that setting is turned off?

@karthiknadig
Copy link
Member

@karthiknadig karthiknadig commented Jul 8, 2019

@RaymonGulati1 Can you get the logs for this? I want to make sure if VS is passing the flag. Wait for exit should not be passed in the attach scenario by the IDE.

On the debugger side, wait for exit should only be applied in the launch case, not for the attach case.

@fabioz
Copy link
Collaborator

@fabioz fabioz commented Jul 8, 2019

It could be that the issue is that it's being started from inside the IDE (with a regular launch), which does initialize some debugging structures (and then it could receive that flag) and then it does a wait for attach from that program and tries to do an attach from the IDE. @RaymonGulati1 can you give more details on how exactly you're making the launch?

-- as a note, I'm not sure we support that scenario well (and it's probably not tested). i.e.: we should make sure that enable attach/wait for attach work when it was already initially launched from the IDE (I vaguely remember that there was some issue based on the initialization without debugging trying to turn debugging on later).

@int19h
Copy link
Contributor

@int19h int19h commented Jul 8, 2019

Note that this is about regular Visual Studio, not VSCode.

In VS, when you do Start without Debugging, it does not launch the process with "nodebug", the way VSCode does. It just launches it directly without ptvsd loaded. Thus, it is perfectly legal to attach to it afterwards.

@int19h
Copy link
Contributor

@int19h int19h commented Jul 8, 2019

With respect to the setting for wait-for-exit - at least one of the bugs here is that this setting is being applied in an attach scenario. It should only apply to launch.

@RaymonGulati1
Copy link
Author

@RaymonGulati1 RaymonGulati1 commented Jul 8, 2019

@fabioz,
Confirming that the settings for "wait for input when process exits normally/abnormally" were turned on. I turned it off and I was able to reproduce it (console closed, but VS is still in debug mode).

@karthiknadig ,
Logs are attached
DebugaAdapterHostLogs-1571.txt

@fabioz, what kind of details? Shoot me a message :)

@int19h
Confirmed.

@fabioz
Copy link
Collaborator

@fabioz fabioz commented Jul 9, 2019

Ok, I downloaded Visual Studio 2019 and I was able to reproduce it there.

It seems to work on the last released version but fails on the current master version.

Some details:

  • The process is dying on both cases (so, it's not some leftover thread).
  • In the version that it works there are messages related to exit in the ptvsd log, whereas in the version that doesn't work the exited/terminated/disconnect are not sent... It seems that there is an issue where ptvsd.daemon.DaemonBase._release_session is called before ptvsd.daemon.DaemonBase._handle_atexit -- i.e.: in the logs where it works there's a call to Handling atexit and later to Stopping daemon and this is reversed in the case that does not work (this is a problem because session will be None in _handle_atexit).
  • It seems there are issues both in Visual Studio as well as ptvsd (i.e.: if the connection is dropped Visual Studio should consider it finished -- regardless of that, the adapter should send the messages at exit properly).
  • On both cases Stopping Daemon appears twice (but in the case where it doesn't work it appears before Handling atexit).
  • I'm attaching the log for the cases where it works and where it doesn't work below.

working_on released_version_ptvsd-4136.log

not_working_on_master_ptvsd-7544.log

@karthiknadig @int19h I know you're working on that area in the refactor branch and it seems this is related to the way the connection in managed (which may be already very different in the refactor branch) -- do you want to take a look at that or should I try to fix that in the current master (even if it'll likely conflict with the branch)?

@RaymonGulati1
Copy link
Author

@RaymonGulati1 RaymonGulati1 commented Jul 9, 2019

@fabioz,

In the latest VS release, the test explorer will always use the legacy debugger. I recently merged the changes into PTVS/master so that the test explorer will use the updated debugger.

@fabioz
Copy link
Collaborator

@fabioz fabioz commented Jul 12, 2019

Note: this is blocked waiting for the refactor branch to be integrated.

@RaymonGulati1
Copy link
Author

@RaymonGulati1 RaymonGulati1 commented Aug 2, 2019

Any idea how long it will take to fix this?

@karthiknadig
Copy link
Member

@karthiknadig karthiknadig commented Aug 2, 2019

It is blocked on #799 . We are currently working on that, and may take one more sprint.

@int19h
Copy link
Contributor

@int19h int19h commented Dec 17, 2019

The problem is that if the attached process gets force-killed, the socket remains open. This will not be detected until the adapter tries to write something into the socket - but it doesn't have any reason to. Conversely, until the adapter sees the socket close, it keeps the socket to the IDE open, and the IDE treats it as a live session.

It looks like we need to implement some kind of heartbeat packets in the adapter.

@int19h
Copy link
Contributor

@int19h int19h commented Dec 18, 2019

Okay, so we do in fact detect the connection being dropped just fine, and if the debuggee process is force-killed directly by PID, e.g. from Task Manager, then everything works (with ptvsd 5).

The problem is when the process is killed by closing its console. In this case, the debuggee and the adapter are both force-killed, and so the adapter doesn't get to report the debuggee going away to the IDE.

I'm going to take a look and see if we can do anything about it. Really adapter just needs to delay long enough that debuggee can exit first. But I'm not sure how reliably we can do this in a cross-platform way.

However, in general, since the adapter can always be force-killed by PID, the IDE should be resilient to this, and detect this situation on its end. VSCode does just that, and works correctly in both scenarios, but the current implementation in VS doesn't detect that socket is closed when the adapter is gone, hence why the debug session is stuck.

@int19h
Copy link
Contributor

@int19h int19h commented Jan 18, 2020

The fix for #2004 should have fixed this.

@int19h int19h closed this Jan 18, 2020
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Linked pull requests

Successfully merging a pull request may close this issue.

None yet
4 participants
You can’t perform that action at this time.