-
Notifications
You must be signed in to change notification settings - Fork 29k
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
Debugging VS Code with VS Code is flaky and frustrating #127861
Comments
For some background: I am trying to use the "VS Code" launch config. I am trying to debug tests with the newish test integration. Symptoms are hangs and crashes, sometimes right after starting, sometimes after reloading, sometimes after the Nth debug attempt. |
/cc @eamodio @rebornix @joaomoreno who have expressed positive or negative emotions towards debugging in the recent past |
I asked in general probably more than twice about how to reliably debug VS Code or tests and also asked for @connor4312 and @roblourens personally for help. Maybe with one more bug to fix the experience can be smooth but I want to share my overall feeling with debugging in VS Code for the last couple of years and workarounds I ended up with
In addition to above, with the extensions starting to use bundler, I sometime find breakpoints doesn't hit in ts file but only in js file, it seems random but when that happens my confidence with source map becomes low and by the end of the day, I stopped using source map in both VS Code and browser dev tools. With that being said, I'm not happy with all the workarounds so often gave the builtin debugger another try, it's getting better though the randomness is still there. I would love to see a clear detailed guidance for troubleshooting (it would be great if it's a command like Toubleshoot Keyboard Shortcuts) and we can file good bug reports. |
Recently talking with @isidorn and @bpasero, we had the idea to have a PM-driven selfhosting effort They would collect information from team members of what the biggest selfhosting pains are and whether and why they are or aren't using VS Code core features. They would then help prioritize work and get it on the plan accordingly. The goal is to maximize selfhosting by putting highlight on areas with most pain. —- Specifically on selfhost debugging: I share your sentiments today. While it was great back in January/February, I can no longer say the same. I subscribe to the lottery analogy, which is the worst situation since it makes us silently ditch the feature, which I’ve certainly done recently. |
I like that and that's also the idea of the |
Here's the state of where the mentioned bugs stand for me:
I will follow up with VS Code team members to gather feedback. |
With regard to debugging tests specifically, I will use the new test run configurations API to allow running in browsers which should some most of these issues (by using a newer Chromium/V8 version where bugs aren't present.) |
For this, I did two things:
Also, for #126826 I noticed that the issue was just that we timed out at all -- it was expected that the ext host didn't launch in that case. |
@connor4312 for #122225 it would help if there are reliable steps to repro the crash, I will add some logs in the runtime this week to better understand the regex causing the crash. |
Debugging a unit test with a breakpoint set anywhere in the codebase reproduces the issue ~50% of the time for me. You can use |
Tried to debug a unit test today and I'm currently seeing from "Test: Show Output"
and logs for
Can we try to detect which process is actually using that port to help us self-troubleshoot what's going on? |
Ok, if you have Remote Container extension installed, it will use Disabling the extension at least gets rid of this error, but now I got an infinite progress of "Running tests", which simply does nothing
|
@chrmarti on the Remote Containers issue Peng mentioned ^ Though I also have and use remote containers and don't see that, so more info may be needed @rebornix I don't repro that,
|
|
@connor4312 here is the log after waiting for a few minutes |
@rebornix thanks, I think I see what's up, seems to be a subtle change in recent Chrome/Electron versions that you're hitting based on timing. Here's a vsix for a nightly build that has a prospective patch: https://memes.peet.io/img/a5d9867c-9921-41e2-843c-163b8eed82a1.vsix |
Followup from PM: this seems to be an Electron bug; a |
When debugging VS Code by using the "VS Code" launch config, I was frequently running into this crash: When trying to understand why/when this happens, I noticed that breakpoints (or the number of breakpoints) are the trigger. Without breakpoints I was never crashing; with around 10 breakpoints crashes occurred 6 out of ten. A workaround is to deactivate all breakpoints temporarily (before running the "VS Code" launch config): and then activating breakpoints individually as soon as the CPU activity has calmed down. |
@rebornix for the freeze issue, can you try running with |
I've now included the aforementioned flag, as well as the flag for the breakpoint crash issue, in the launch config and selfhost test provider by default. |
Is there a way to set this flag in a config file instead of editing the shortcut which opens VSC? |
There have been no further problems shared here, outstanding issues are tracked separately. Thus closing. |
Sorry, that's it. Cannot say more, the experience is a lottery - it sometimes works flawless, it sometimes doesn't work. That it works only randomly is frustrating but what's worst is that I don't feel empowered to provide any kind of qualified feedback. I cannot file good issues and have to resort to ranting. I believe most have confirmed the broken window theory and just moved back to devtools or never made the switch.
The text was updated successfully, but these errors were encountered: