After upgrade to 2025.0.0 : "Server[pid=x] is already being debugged" error

Hello,

since I upgraded to version 2025.0.0, I get error "Server[pid=x] is already being debugged" while debugging Python Azure Function.

if I downgrade to version 2024.14.0 it is working fine.

VSCode on Mac :

Version: 1.97.0
Commit: 33fc5a94a3f99ebe7087e8fe79fbe1d37a251016
Date: 2025-02-04T22:41:26.688Z (2 days ago)
Electron: 32.2.7
ElectronBuildId: 10660205
Chromium: 128.0.6613.186
Node.js: 20.18.1
V8: 12.8.374.38-electron.0
OS: Darwin x64 20.6.0

launch.json

{
    "version": "0.2.0",
    "configurations": [
        {
            "name": "Attach to Python Functions",
            "type": "debugpy",
            "request": "attach",
            "connect": {
                "host": "localhost",
                "port": 9091
            },
            "preLaunchTask": "func: host start",
            "logToFile": true,
        }
    ]
}

ms-python.debugpy log file

0 Starting Session:
{
    "name": "Attach to Python Functions",
    "type": "debugpy",
    "request": "attach",
    "connect": {
        "host": "localhost",
        "port": 9091
    },
    "preLaunchTask": "func: host start",
    "logToFile": true,
    "__configurationTarget": 6,
    "clientOS": "unix",
    "debugOptions": [
        "RedirectOutput",
        "ShowReturnValue"
    ],
    "justMyCode": true,
    "showReturnValue": true,
    "workspaceFolder": "/Users/xxx/Workspace/xxxFunctionApp"
}
3 Client <-- Adapter:
{
    "seq": 1,
    "type": "event",
    "event": "output",
    "body": {
        "category": "telemetry",
        "output": "ptvsd",
        "data": {
            "packageVersion": "1.8.12"
        }
    }
}
3 Client <-- Adapter:
{
    "seq": 2,
    "type": "event",
    "event": "output",
    "body": {
        "category": "telemetry",
        "output": "debugpy",
        "data": {
            "packageVersion": "1.8.12"
        }
    }
}
10 Client --> Adapter:
{
    "command": "initialize",
    "arguments": {
        "clientID": "vscode",
        "clientName": "Visual Studio Code",
        "adapterID": "debugpy",
        "pathFormat": "path",
        "linesStartAt1": true,
        "columnsStartAt1": true,
        "supportsVariableType": true,
        "supportsVariablePaging": true,
        "supportsRunInTerminalRequest": true,
        "locale": "en",
        "supportsProgressReporting": true,
        "supportsInvalidatedEvent": true,
        "supportsMemoryReferences": true,
        "supportsArgsCanBeInterpretedByShell": true,
        "supportsMemoryEvent": true,
        "supportsStartDebuggingRequest": true,
        "supportsANSIStyling": true
    },
    "type": "request",
    "seq": 1
}
12 Client <-- Adapter:
{
    "seq": 3,
    "type": "response",
    "request_seq": 1,
    "success": true,
    "command": "initialize",
    "body": {
        "supportsCompletionsRequest": true,
        "supportsConditionalBreakpoints": true,
        "supportsConfigurationDoneRequest": true,
        "supportsDebuggerProperties": true,
        "supportsDelayedStackTraceLoading": true,
        "supportsEvaluateForHovers": true,
        "supportsExceptionInfoRequest": true,
        "supportsExceptionOptions": true,
        "supportsFunctionBreakpoints": true,
        "supportsHitConditionalBreakpoints": true,
        "supportsLogPoints": true,
        "supportsModulesRequest": true,
        "supportsSetExpression": true,
        "supportsSetVariable": true,
        "supportsValueFormattingOptions": true,
        "supportsTerminateRequest": true,
        "supportsGotoTargetsRequest": true,
        "supportsClipboardContext": true,
        "exceptionBreakpointFilters": [
            {
                "filter": "raised",
                "label": "Raised Exceptions",
                "default": false,
                "description": "Break whenever any exception is raised."
            },
            {
                "filter": "uncaught",
                "label": "Uncaught Exceptions",
                "default": true,
                "description": "Break when the process is exiting due to unhandled exception."
            },
            {
                "filter": "userUnhandled",
                "label": "User Uncaught Exceptions",
                "default": false,
                "description": "Break when exception escapes into library code."
            }
        ],
        "supportsStepInTargetsRequest": true
    }
}
13 Client --> Adapter:
{
    "command": "attach",
    "arguments": {
        "name": "Attach to Python Functions",
        "type": "debugpy",
        "request": "attach",
        "connect": {
            "host": "localhost",
            "port": 9091
        },
        "preLaunchTask": "func: host start",
        "logToFile": true,
        "__configurationTarget": 6,
        "clientOS": "unix",
        "debugOptions": [
            "RedirectOutput",
            "ShowReturnValue"
        ],
        "justMyCode": true,
        "showReturnValue": true,
        "workspaceFolder": "/Users/xxx/Workspace/xxxFunctionApp",
        "__sessionId": "xxx"
    },
    "type": "request",
    "seq": 2
}
14 Client <-- Adapter:
{
    "seq": 4,
    "type": "event",
    "event": "debugpyWaitingForServer",
    "body": {
        "host": "127.0.0.1",
        "port": 50981
    }
}
23 Client <-- Adapter:
{
    "seq": 5,
    "type": "response",
    "request_seq": 2,
    "success": false,
    "command": "attach",
    "message": "Server[pid=18781] is already being debugged."
}
24 Client --> Adapter:
{
    "command": "disconnect",
    "arguments": {
        "restart": false
    },
    "type": "request",
    "seq": 3
}
25 Client <-- Adapter:
{
    "seq": 6,
    "type": "event",
    "event": "terminated"
}
26 Client <-- Adapter:
{
    "seq": 7,
    "type": "response",
    "request_seq": 3,
    "success": true,
    "command": "disconnect"
}
26 Stopping Session
28 Error:
{}

SherekhanFR

SherekhanFR I downgraded the version of the extension "Python Debugger" to v2024.14.0, now debugging of azure functions is working again

thank you for downgrading the version of the extension "Python Debugger" to v2024.14.0. It solved my issue too.

This happens when I have multiple VS Code windows open with Python projects:

run debugpy from the terminal as per No‐Config Debugging
notice the other VS Code windows error with "Server[pid=x] is already being debugged"

These are standard python projects, not Azure functions.

This is particular annoying - is there a way to disable the new No‐Config Debugging and only opt-into that feature?

Same issue here. An opt out would be highly appreciated. I suspect it has to do when multiple windows are open, causing multiple windows to try to connect and oftentimes the wrong window ending up connecting....

Yep indeed - my current workaround is to close all other windows except the one for the repo I'm trying to debug, but this is kind of a time-sync [I'd rather prefer having the option to / being able to attach to a remote debug server "manually" as before].

I also tried to remove all debug configurations that reference the respective port that debugpy is listening on hoping that then that particular window won't try to connect, but seems like the debug configs aren't even respected by the no-config debugging [as the name suggests 😄]

Hi! Sorry about this. Can people describe how exactly they are debugging and the expected vs actual behavior. Are people trying to debug through the terminal without using no-config debug? By multiple windows can you describe those more, are they windows in the same workspace?

I want to add that I receive this error with only one VS Code instance open, but then again I'm using the "Blender Development" extension which attaches the Python debugger to Blender behind the scenes, showing said message box. (I also returned to the last 2024 version to get around this issue.)

The first pre-release version where this issue appears is 2024.15.2025011702

Eleanor Boyd (@eleanorjboyd)

Eleanor Boyd (@eleanorjboyd).

My environment

I work in a monorepo and use git worktree to check out multiple branches in parallel, each branch checked out in a different folder. I have a vscode window open at the root of each checked out branch.
- For context: git worktree allows me to have 1 bare clone of the repo and then have multiple branch checkout folders from that bare clone. On disk, it is very similar to just having multiple clones of the same repo in different folders, except that its much more disk-storage efficient (you only need to maintain 1 git graph, including the fetched origin, on disk).
- Another peculiar thing about my setup is that all my branch checkout folders use the same .vscode workspace settings folder: At the root of each branch checkout folder I have a symlink to 1 shared .vscode workspace settings folder. This is to work around limitations of the VS Code config system (let's not go into that here).
I start my command from the VS Code integrated terminal. I set up the debug server programmatically in my command (this is because of how it integrates with the bazel build system I use), as shown below.
Additionally, some tricks are done to make the python program hermetic in the bazel build system. I don't think its relevant, but just putting it out there in case there is overlap with the environment of others following this ticket.
I never opted in to no-config. I think the ability to opt-out is a must have (although I agree that moving towards not needing to ever opt out is desirable, I doubt how realistic that is in short term).
- Even without the multi-window issue that we're all having, I think allowing people to opt out of no-config is desirable, as it allows tweaking the config settings (e.g. to tweak the justMyCode setting).

Expected vs actual

Expected behavior: waiting for me to attach (which I'd starting a debugging sessions using my own launch.json debugging config)
Actual behavior: auto-attaches and generally attaches to the wrong window. I'm getting error "Server[pid=x] is already being debugged" in all (or some?) other windows. My mileage varies (sometimes it doesn't even try to auto attach?).

More details on my setup

Programatic debugger setup:

os.environ["PYDEVD_RESOLVE_SYMLINKS"] = "1"
debugpy.listen(("localhost", 5678))
debugpy.wait_for_client()

launch.json config entry:

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

Explaining my folder setup:

$HOME/dev
- bare_clone (for git worktree)
- worktree_checkout_branch1: based off bare_clone.
  - .vscode -> $HOME/dev/.vscode (symlink)
- worktree_checkout_branch2: based off bare_clone.
  - .vscode -> $HOME/dev/.vscode (symlink)
- .vscode

Eleanor Boyd (@eleanorjboyd)

Eleanor Boyd (@eleanorjboyd), could we prioritize providing an extension setting to disable no-config?

Hello! Apologies on missing responding to this thread! I have made a change to how no-config debugging works that should solve the issue you are facing since it only does setup for no-config debug once you have called it which will stop it from conflicting with existing work scenarios that use debugpy from the terminal as is. I added in in response to this other thread but forgot to tag this thread as a duplicate of it. This fix is out on the pre-release of the debugger extension so if anyone gives it a try please let me know if it does in fact fix your bug. Thanks!

Thanks. I'll give it a spin. I'd still strongly suggest we add an explicit opt-out preference.

Karthik Nadig (@karthiknadig)

looping in Karthik Nadig (@karthiknadig) and Courtney Webster (@cwebster-99) for their thoughts on that explicit setting

Can confirm that the "Blender Development" extension no longer shows the message and works as before / as it should.

Eleanor Boyd (@eleanorjboyd)

Eleanor Boyd (@eleanorjboyd) I think your fix decouples the debugpy env variable switch that case this issue. Let us see, if there are cases where it interferes with running debugpy directly. We can add a setting if it does.

Navigation Menu

Repository navigation

After upgrade to 2025.0.0 : "Server[pid=x] is already being debugged" error #592

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

After upgrade to 2025.0.0 : "Server[pid=x] is already being debugged" error #592

Description

Activity

andriimazur93 commented on Feb 12, 2025

OmidGhotbi commented on Feb 16, 2025

tekumara commented on Feb 18, 2025

janickm commented on Feb 18, 2025

koenlek commented on Feb 19, 2025

janickm commented on Feb 19, 2025

eleanorjboyd commented on Feb 19, 2025

RayKoopa commented on Feb 19, 2025

koenlek commented on Feb 19, 2025

koenlek commented on Feb 26, 2025

eleanorjboyd commented on Feb 26, 2025

koenlek commented on Feb 26, 2025

eleanorjboyd commented on Feb 26, 2025

RayKoopa commented on Feb 26, 2025

karthiknadig commented on Feb 26, 2025

Metadata

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

Issue actions