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

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

Open
SherekhanFR opened this issue Feb 7, 2025 · 9 comments
Assignees
Labels
triage-needed Needs assignment to the proper sub-team

Comments

@SherekhanFR
Copy link

Hello,

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

Image

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:
{}
@github-actions github-actions bot added the triage-needed Needs assignment to the proper sub-team label Feb 7, 2025
@eleanorjboyd eleanorjboyd self-assigned this Feb 10, 2025
@andriimazur93
Copy link

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

@OmidGhotbi
Copy link

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

@tekumara
Copy link

tekumara commented Feb 18, 2025

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

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

These are standard python projects, not Azure functions.

@ph03
Copy link

ph03 commented Feb 18, 2025

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

@koenlek
Copy link

koenlek commented Feb 19, 2025

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....

@ph03
Copy link

ph03 commented Feb 19, 2025

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

@eleanorjboyd
Copy link
Member

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?

@RayKoopa
Copy link

RayKoopa commented Feb 19, 2025

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

@koenlek
Copy link

koenlek commented Feb 19, 2025

@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

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
triage-needed Needs assignment to the proper sub-team
Projects
None yet
Development

No branches or pull requests

8 participants