-
Notifications
You must be signed in to change notification settings - Fork 119
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
VSCode 1.66.0 appears to have broken Native Debug #335
Comments
I am using an ESP32 and the ESP-Prog. Here is a repository I followed to get setup. Specifically, here is the {
// Use IntelliSense to learn about possible attributes.
// Hover to view descriptions of existing attributes.
// For more information, visit: https://go.microsoft.com/fwlink/?linkid=830387
"version": "0.2.0",
"configurations": [
{
"name": "ESP-Prog Debug",
"type": "gdb",
"request": "launch",
"target": "./build/esp_prog_vscode_debug.elf",
"cwd": "${workspaceRoot}",
"env": {
"PATH": "${config:esp_toolchain_paths}:${env:PATH}"
},
"gdbpath": "xtensa-esp32-elf-gdb",
"preLaunchTask": "Launch OpenOCD GDB Server",
"autorun": [
"target extended-remote :3333",
"mon reset halt",
"flushregs",
"thb app_main",
"c",
"monitor [target current] configure -event gdb-detach { shutdown }",
],
}
]
} Here is the pre-launch task, from {
// See https://go.microsoft.com/fwlink/?LinkId=733558
// for the documentation about the tasks.json format
"version": "2.0.0",
"tasks": [
{
"label": "Launch OpenOCD GDB Server",
"type": "shell",
"isBackground": true,
"options": {
"cwd": "${workspaceRoot}",
"env": {
"PATH": "${config:esp_toolchain_paths}:${env:PATH}"
}
},
"command": "openocd -f interface/ftdi/esp32_devkitj_v1.cfg -f target/esp32.cfg",
"problemMatcher": {
"pattern": {
"regexp": "(Error|Warn) ?: .*",
"file": 1,
"location": 2,
"message": 3
},
"background": {
"activeOnStart": true,
"beginsPattern": "Open On-Chip Debugger.*",
"endsPattern": "Info : Listening on port [0-9]{1,5} for gdb connections"
}
}
},
...
]
} |
please share a session log of the working and not-working environment doing the same after adding |
I don't have the ability to debug the debugger at the moment. FWIW, I was able to switch over to the Microsoft debugger and get it to connect, although it's not working flawlessly either. The most curious thing is, everything works perfectly when run directly from the command line. |
Doesn't work on Linux or Windows either (x64 for remote debugging on 32 bit arm) for me. It used to throw an exception on some machines and then just continue on just fine, now it just never connects to the remote target.
|
I added
|
That is a good start - if you can now provide the same with an older vscode version where it works we'd have everything needed to check for the actual difference. |
Here's a log from 1.65.2. Starting the program and then stepping a couple of times before killing it
|
I took a look at this today. I wasn't able to replicate this with the latest in the repository, so I ran against the last released version (i.e., v0.25.1) and was able to reproduce the symptoms. I was pretty sure this was being caused by an internal exception within the debug adapter. Therefore, I pulled the commit for this version from the repository and ran the same scenario. The scenario I used was just an attach using a remote gdbserver. The issues identified above showed both a launch which ultimately used an extended remote, and also an attach to a remote server. I constructed a simple attach to a remote gdbserver, so that I could test this without special hardware. With this setup, I was able to run the v0.25.1 version of the debug adapter within the node debugger and was able to pin-point the source of the issue. InvestigationSo this appears to be an unhandled exception when the Workaround / ConfirmationThe fix in #282 should be in the next released version of the debug adapter, but for now you should be able to work around and confirm the issue by patching the installed version to apply the changes as performed in #282. The following shows the diff that you can apply to the installed version of the extension, which should be located at threadsRequest(response) {
if (!this.miDebugger) {
this.sendResponse(response);
return;
}
this.miDebugger.getThreads().then(threads => {
response.body = {
threads: []
};
for (const thread of threads) {
let threadName = thread.name || thread.targetId || "<unnamed>";
response.body.threads.push(new vscode_debugadapter_1.Thread(thread.id, thread.id + ":" + threadName));
}
this.sendResponse(response);
+ }).catch(error => {
+ this.sendErrorResponse(response, 17, `Could not get threads: ${error}`);
});
} |
Thanks for this thorough check and explanation! So "luckily" we can close this as "already solved", @brownts if I don't do it today As you were able to debug the debugger, it seems you could help with #176. |
The VSCode team made multiple updates to debugging, and it appears one is incompatible with Native Debug.
Changes:
Experience: No errors are thrown on any of the VSCode windows, and the debugger appears to work momentarily, but it immediately detaches before hitting any breakpoints.
When I revert to VSCode 1.65.2, then everything works as expected.
The text was updated successfully, but these errors were encountered: