PTVS
PTVS copied to clipboard
Unexpected error pops up in the console when attach a running python.exe
Environment

Steps to Reproduce 1.Launch VS and create new python application 2.Add an input('>') or raw_input('>') at the top of your code - depends on version of python 3.Add some more python code after that with breakpoint(s) 4.Start WITHOUT debugging a. Console will wait for you to input something 5.Debug > Attach to Process, select the appropriate python.exe (easiest if there's only one, you may want to close interactive windows first) 6.Type enter in the console 7.Check that it stops at the breakpoint
Expected behavior It stops at the breakpoint without any errors
Actual behavior
The cmd console shows this

Additional context and screenshots

Sample Code
input('>')
from math import cos, radians
# Create a string with spaces proportional to a cosine of x in degrees
def make_dot_string(x):
rad = radians(x) # cos works with radians
numspaces = int(20 * cos(radians(x)) + 20) # scale to 0-40 spaces
st = ' ' * numspaces + 'o' # place 'o' after the spaces
return st
def main():
for i in range(0, 1800, 12):
s = make_dot_string(i)
print(s)
main()
On today's environment
Still failed to hit the breakpoint and an error dialog displayed at the end of the attach.

Does it make any difference if you do import threading in the script?
@int19h
on today's build, i can repro these two phenomena ,though i do 'import threading' in the script

Situation1(the breakpoint is hit)

Situation2(the breakpoint isn't hit)

NOTE:
The operation steps are the same in both situation, the only difference is that the waiting time is different before Type enter in the console(situation1 is typing enter after waiting some seconds, situation2 is typing enter immediately)
Without import threading, the warning printed to console is expected. Note that it must be imported before you attach (i.e. before input())!.
The error message box you sometimes get with import threading about server failing to attach appears to be a timing issue. Attach-to-PID is inherently asynchronous as it has to inject itself into a running Python thread using Py_AddPendingCall. It is entirely possible for the app to run to completion before the pending call is actually processed by the runtime, at which point the app exits while PTVS is still waiting for the injected code to connect back to it. There's nothing we can really do here as we don't have control or even insight over the debuggee until injection actually completes. This is usually not an issue in practice because attach-to-PID is normally used to attach to long-running processes; in this case, you can simulate it by calling main repeatedly in a loop, and in that repro, the breakpoint is consistently hit as espected.