Not able to get debugpy attach (PID and host & port) working inside Zed code editor #1820
Comments
|
Have you tried doing the same thing in VS code with logging and see what the difference is in the debupgy and vscode logs and your output? That's what I'd do to debug the problem. |
|
Hey, thanks for the fast response! Yeah, we already tried sending the same information as vscode does with their requests, Here is the log from the same attach flow in vscode0 Starting Session:
{
"name": "Python Debugger: Attach Port",
"type": "debugpy",
"request": "attach",
"connect": {
"port": 5678,
"host": "127.0.0.1"
},
"logToFile": true,
"__configurationTarget": 6,
"clientOS": "unix",
"debugOptions": [
"RedirectOutput",
"ShowReturnValue"
],
"justMyCode": true,
"showReturnValue": true,
"workspaceFolder": "/Users/remcosmits/Documents/code/test-python-project"
}
5 Client <-- Adapter:
{
"seq": 1,
"type": "event",
"event": "output",
"body": {
"category": "telemetry",
"output": "ptvsd",
"data": {
"packageVersion": "1.8.12"
}
}
}
5 Client <-- Adapter:
{
"seq": 2,
"type": "event",
"event": "output",
"body": {
"category": "telemetry",
"output": "debugpy",
"data": {
"packageVersion": "1.8.12"
}
}
}
5 Client <-- Adapter:
{
"seq": 3,
"type": "event",
"event": "debugpySockets",
"body": {
"sockets": [
{
"host": "127.0.0.1",
"port": 5678,
"internal": false
},
{
"host": "127.0.0.1",
"port": 53180,
"internal": true
}
]
}
}
7 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
}
7 Client <-- Adapter:
{
"seq": 4,
"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
}
}
14 Client --> Adapter:
{
"command": "attach",
"arguments": {
"name": "Python Debugger: Attach Port",
"type": "debugpy",
"request": "attach",
"connect": {
"port": 5678,
"host": "127.0.0.1"
},
"logToFile": true,
"__configurationTarget": 6,
"clientOS": "unix",
"debugOptions": [
"RedirectOutput",
"ShowReturnValue"
],
"justMyCode": true,
"showReturnValue": true,
"workspaceFolder": "/Users/remcosmits/Documents/code/test-python-project",
"__sessionId": "aa999f13-3d1b-4366-8dd7-c3429c05848f"
},
"type": "request",
"seq": 2
}
14 Client <-- Adapter:
{
"seq": 5,
"type": "event",
"event": "debugpyWaitingForServer",
"body": {
"host": "127.0.0.1",
"port": 53180
}
}
21 Client <-- Adapter:
{
"seq": 6,
"type": "event",
"event": "initialized"
} |
|
It looks like in your case the initialized event is not coming back. That should happen as a result of the attach request. That's here: I guess I'd add more logging to pydevd and then look at the pydevd.log that should have been generated to see why it's not making to the initialized event that should occur. |
|
You can add more logging with lines like this: pydev_log.debug("Any string") |
|
Thanks for your help so far, will look into this more this weekend will let you know if I need some more guidance. |
|
Where should the |
|
Not sure if It's related, but I also get the following error back from the dap server, when I'm trying to use the attach process feature. I also get this when I'm trying this feature inside VSCode. E+00001.884: Code injection into PID=39241 failed --- Starting attach to pid: 39241 ---\n(lldb) process attach --pid 39241\nProcess 39241 stopped\n* thread #1, queue = 'com.apple.main-thread', stop reason = signal SIGSTOP\n frame #0: 0x000000018ca3a6ec libsystem_kernel.dylib |
|
Attach failing to inject would certainly prevent attach from working. The inject logic uses gdb on mac to inject python code into the process that gets debugpy working. Your attach problem might be this: As for the log, the PYDEVD_DEBUG_FILE should be where it writes the log. In debugpy this is set here: |
|
Thanks for the heads up @rchiodo. MacOS on Arm doesn't support gdb is there a work around Remco and I could use to get it working with lldb? |
|
Sorry I mispoke, mac uses lldb already. This code here: There were some issues that I was having trouble finding where the debugger would actually break on enter instead of just running and evaling. Those issues if I recall correctly were on Mac. |
|
Ah this one. Attach doesn't work on arm, probably because the dylib isn't compiled for arm: |
Hi debugpy team,
I'm one of the guys that is working on the client-side implementation of the DAP spec for the Zed code editor.
We are struggling a bit to get the attach (PID and host & port) feature to work, and haven't found any documentation on how to do it.
Could you please point me in the right direction to find out how to configure debugpy to work with attach?
About our implementation:
We use the debugpy library that is installed inside the user’s virtual environment. We start the debug adapter with the following command:
Our Setup
We start a simple Python script with the following commands:
Add the following content to the
test.pyfile:Start to listen for debugger:
Our Issue
So one of the issues we are facing is that we never receive an attach response back, so it seems like debugpy is waiting for something/someone. So I looked at our request/response log which shows that we receive two custom events debugpySockets and debugpyWaitingForServer. Which results into the following error log
Cancelled DAP request for "attach" id 2 which took over 12s.Which to my understanding is not more than just an informational event, to notify us about the sockets it is listening on and that it is waiting for a server to connect to it. So while I was debugging this issue, I looked at the vscode-python-debugger implementation, it seems like they don't really act on these events.
So my first question is should we act on these events? And if so, how should we act on them?
I also read through some of the debugpy internal code, which seems to support the StartDebuggingRequest reverse request, so should we act on these events if we could receive the StartDebuggingRequest request?
I've seen examples online where two instances of debugpy are run, one for the debuggee program and another to connect to the first instance. Is this a pattern that we'll have to replicate?
Request log for debugpy attach
The text was updated successfully, but these errors were encountered: