Python debugger under attach mode randomly connect a vscode instance

[ytwanghaoyu]

Type: Bug

Behaviour

I have my python debugpy config set like this:

  {
    "name": "Python: Attach",
    "type": "debugpy",
    "request": "attach",
    "connect": {
      "host": "localhost",
      "port": 5678
    }

And when I open like 2 vscode window, and it just randomly attach to one of them, and raise an error on the other one.

Error: Server[pid=****] is already being debugged.

Possible additional info for you to debug:

1. My debug config is saved in setting.json as global synced config.

2. My python version is 3.8.10

3. Before this error happens, I need to manually press F5 to attach to my program, but at some time (At least two months ago) It just automatically attached to my vscode debugger.

4. In the code I use a code like this to wait for debugpy attaching

    import debugpy
   
    debugpy.listen(port)
    print('\033[91m' + 'Waiting for debugger attach' + '\033[0m')
    debugpy.wait_for_client()
    print('\033[92m' + 'Debugger attached' + '\033[0m')
   

Steps to reproduce:

1. Just open more than one vscode window, and use debugpy to attach to your running program

Diagnostic data

launch.json configuration

XXX

Output for Python in the Output panel (View→Output, change the drop-down the upper-right of the Output panel to Python)

XXX

Output for Python Debugger in the Output panel (View→Output, change the drop-down the upper-right of the Output panel to Python Debugger)

XXX

Extension version: 2025.1.2025022401
VS Code version: Code 1.97.2 (e54c774e0add60467559eb0d1e229c6452cf8447, 2025-02-12T23:20:35.343Z)
OS version: Linux x64 5.15.0-67-generic
Modes:
Remote OS version: Linux x64 5.15.0-130-generic

• Python version (& distribution if applicable, e.g. Anaconda): 3.8.10
• Type of virtual environment used (e.g. conda, venv, virtualenv, etc.): Unknown

System Info

Item	Value
CPUs	Intel(R) Xeon(R) W-2245 CPU @ 3.90GHz (16 x 1288)
GPU Status	2d_canvas: enabled canvas_oop_rasterization: enabled_on direct_rendering_display_compositor: disabled_off_ok gpu_compositing: enabled multiple_raster_threads: enabled_on opengl: enabled_on rasterization: enabled raw_draw: disabled_off_ok skia_graphite: disabled_off video_decode: enabled video_encode: disabled_software vulkan: disabled_off webgl: enabled webgl2: enabled webgpu: disabled_off webnn: disabled_off
Load (avg)	3, 3, 2
Memory (System)	125.50GB (86.61GB free)
Process Argv
Screen Reader	no
VM	0%
DESKTOP_SESSION	ubuntu
XDG_CURRENT_DESKTOP	Unity
XDG_SESSION_DESKTOP	ubuntu
XDG_SESSION_TYPE	x11

[ytwanghaoyu]

Seems similar as #592

[ytwanghaoyu]

The timeline of the issue #592 is consistent with what I encountered.

In an update two months ago, I no longer needed to click F5 myself to attach to a Python program (which is good), but initially, there was often a loss of debugging capability (for example, one VSCode instance just couldn't connect to debugpy, indicating port occupation and such). In recent version updates, this problem has been fixed, but there's now a random attachment to a VSCode window situation that is very annoying. Especially when you have 4-5 VSCode windows open at the same time.

[karthiknadig]

@ytwanghaoyu This is expected, if you use the same port on both instances of VS Code this can happen. When you launch debugpy you have to use different port numbers on debugpy.listen ans update launch json to use connect with the same port number.

Alternatively, you can also get rid of the configuration entirely and just use `no-config debugging. see here: https://devblogs.microsoft.com/python/python-in-visual-studio-code-february-2025-release/#no-config-debugging

[ytwanghaoyu]

When I revert my python debugger version back to V2024.14.0, everything seems to be work just fine.

Except I can somehow reproduce my former error

For this error, I'm not quite sure how to ensure 100% reproduction of the problem.

The timeline of the issue #592 is consistent with what I encountered.

In an update two months ago, I no longer needed to click F5 myself to attach to a Python program (which is good), but initially, there was often a loss of debugging capability (for example, one VSCode instance just couldn't connect to debugpy, indicating port occupation and such). In recent version updates, this problem has been fixed, but there's now a random attachment to a VSCode window situation that is very annoying. Especially when you have 4-5 VSCode windows open at the same time.

[ytwanghaoyu]

@ytwanghaoyu This is expected, if you use the same port on both instances of VS Code this can happen. When you launch debugpy you have to use different port numbers on debugpy.listen ans update launch json to use connect with the same port number.

Alternatively, you can also get rid of the configuration entirely and just use `no-config debugging. see here: devblogs.microsoft.com/python/python-in-visual-studio-code-february-2025-release#no-config-debugging

Thanks for your reply.

We are working under a bazel workspace, where everything needs to be run under bazel run, which means that no-config debug (run debugpy directly to a python file) is not available.

That is also the reason why we choose to use attach mode instead of launch mode

[ytwanghaoyu]

Setting a listen port for each vscode instance may be very inconvenient.

For example, when you use git worktree for development or multi-workspace development, every time you run it, you need to pass in the corresponding port listened to by vscode. This will obviously intrude into the user's code (such as specifying through a flag or through an environment variable, etc.). All these are detrimental to the original universal and simple debug code mode.

For example, code formally:

import debugpy

debugpy.listen(port)
print('\033[91m' + 'Waiting for debugger attach' + '\033[0m')
debugpy.wait_for_client()
print('\033[92m' + 'Debugger attached' + '\033[0m')

needs to be changed to

import debugpy
import argparse

# User may use jsonargparse / click / absl FLAGS / or even directly parse from sys
def parse_args():
	.....
	return args

debugpy.listen(args.port)
print('\033[91m' + 'Waiting for debugger attach' + '\033[0m')
debugpy.wait_for_client()
print('\033[92m' + 'Debugger attached' + '\033[0m')

I do understand sharing same port number among different vscode instances for auto-listening is not a good practice. But I believe therer might be a better way to handle this.

[karthiknadig]

can you turn the connections around? use listen on VS Code side and Connect on debugpy side. You could create a launch config like this:

The task can take environment variables so you can pass whatever port number you like for each instance. Note that the task could be written to launch bazel workspace instead. in your code all you would need to do is debugpy.connect(os.getenv('CUSTOM_PORT'))

[ytwanghaoyu]

Ohhhh thath's cool to know that debugpy can be used in this way. This is indeed a clever method. I will test if there are any problems.

[ytwanghaoyu]

The bazel run won't return the finish code until target is finished running. Therefore the bazel run command still needs to be performed in command line. (I think separate bazel build and ./bazel-bin run with background task might also solve this.)

Besides, this method works very well.

[eleanorjboyd]

Closing since it seems like this new method is going well- lmk if there is still a problem you are facing and I can reopen