PTVSD Debugging after python process has exited.

[RaymonGulati1]

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

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

[karthiknadig]

Dupe #1553

[karthiknadig]

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

[fabioz]

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]

@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]

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]

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]

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]

@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]

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]

@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]

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

[RaymonGulati1]

Any idea how long it will take to fix this?

[karthiknadig]

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

[int19h]

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]

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]

The fix for #2004 should have fixed this.