jiebi/CodeConvo huggingface dataset:
over the last week I have seen zombie processes running at full CPU load when trying to debug them (via SIGUSR1) they die analysed a crash dump and sees that this is because the EH is already in the process of shutting down the previous point matches the observation that no window reports its EH as having crashed <img width="1290" alt="Screenshot 2023-09-29 at 13 31 34" src=""
Can you take a process sample from the OS activity monitor, I hope the native stack can give a clue to what is happening.
Just happening. This is the command line of such an EH
This the process sample
Not sure about the part. Does this mean we run the EH under development or not?
It looks like we set that for all local EH process launches. Just having inspect-port doesn't put the process in debug mode. What you can do is use the "Debug: Attach to Process" command and select that process. This will fail, since the debugger won't then know what port it's listening on (if --inspect-port isn't given in the args, it always listens on 9229, and js-debug assumes that is what happens). But, then you can . AFter doing so you could grab a performance profile using the edge/chrome devtools on edge://inspect, or by attaching to that using an attach-type launch config VS Code and using the "take performance profile" command -- if the spin sample you recorded above isn't enough for Deepak to figure out what's going on.
Does that use SIGUSR1? Asking cos I have tried that first and sending the signal kills the process. From the crash dumps we do know that the process already was shutting down
Attaching the symbolicated sample Going from the top, indicates the EH process is already in the shutdown phase and has started to destroy the . At this point, connecting via a debugger is not possible since the agent host will stop receiving connections due to the following , so we cannot get perf profile from these processes. Moving further down most of the sample time is spent in which the environment gets deleted, this flushes the pending tasks in the libuv event loop but one thing to note is that entering JS via these tasks is not allowed due to the . But there are GC tasks being executed and which can enter JS.
I think the error calls ` are from these callsites eventually leading to . At this point, I expect the process to abort and the main process should be able to reap the utility process but that is not happening. There is another data point looking back at the screenshot from , the zombie EH processes are titled and not in the process explorer. We resolve the pids to respective titles based on a map maintained in the main process, the process explorer gets it periodically via the following and the utility process related values are populated from . We default to when the pid map no longer has an entry for the process which can only happen when got invoked which inturn suggests that the main process did receive an exit or crash signal from these EH hosts. can you check the main process logs next time if it has any of the following entries for the corresponding zombie EH pid to validate this data
I attempted to setup a similar flow based on the stack with base Electron app but the utility process are cleaned up as expected. I can make a change in the destruction phase of the utility process to signal termination of isolate so that tasks which require to enter JS will not do so and I hope that resolves the long running draintask. I won't be able to make a new insiders build with this change until I am back from vacation but I can provide a custom electron build for local testing with OSS. would that help to validate incase you face similar issue with OSS as well ?
Ah, my bad, skimmed over that part. Disregard. (Yes, it sends SIGUSR1 on unix)
I am seeing this for which is currently spinning forever. Samples for this one
i think i have the same issue on my mac. It happens from time to time and my workaround is simply killing vscode and then reopen it. But sometimes i don't realize it until my Mac has run out of battery, which can be quite annoying. <img width="963" alt="CleanShot 2023-10-09 at 19 46 49 src=""!
Having the exact same issue. utility-process is running at 100% all the time on M1 Max, very annoying.
This bug might also exist in Linux build of vscode: ! (6% 16 cores = 96%) Command line of "utility-process" is: eu-stack of main thread of this process: Noticed that is also inside sampling.
Manually sampling with eu-stack running every second, for one minute. (And might related to and )
Sorry if I'm hijacking the thread but would uninstalling Node and installing Bun solve this problem? Doesn't sound like it's a VSCode bug, right?
Thanks for the logs , the stack does look related. I wouldn't be surprised if the issue is also present on Linux since the shutdown path is same for both.
Similar issue on my M1 Max, sometimes I observe even 3/4 zombie processes running in the background and have to kill them manually from process manager to stop them from draining battery. 2 more samples for such process:
Checked log and it looks weird. : However, PID still exists and is running at 100%.
Another hang process today with log: "Extension host with pid started" "Extension host with pid exiting with code 0" "Extension host with pid exited with code: 0, signal: unknown."
Is there any temp workaround? any script or bash command that we can run to identify and kill those pid? I am interested to do it manually, because i have a M2 and i am rebooting my macbook after some hours because get soooo slow
Restarting VS Code should already "fix" the problem because the extension host is a child process of the application. At least that does the job for me. Are you observing a different behavior? Note that "Reload Window" does not kill the zombie process (according to my observation).
Please help by posting the list of installed extensions. I am looking for similarities between our setups as this is possibly caused by an extension. This is my list To get this list run or . Please do the same and post your results here. Thanks
Thanks for looking into this! I am also facing this issue quite frequently. Here are my installed extensions:
Thanks everyone. Looks like the intersection is
code --list-extensions
Yep, I'm using those extensions too. Here's the full list:
is not a very good workaround: what if the process exits, but another innocent process just takes this PID?
It probably cannot do that as the pid is still taken? I agree it's not a great workaround, but until the root cause is clear it does solve the issue where a cpu is occupied.
Type: <bBug</bIn previous VS Code version 1.78 when I pressed if inline suggest was visible with suggest widget it hides only inline suggest, if I press again same shortcut it then hides suggest widget. Now with 1.79 it hides both inline suggest and suggest widget. KeybindingService logs: My custom shortcuts to hide inline suggest & suggest widget: I even tried to add to clause and still it hides both. VS Code version: Code 1.79.0 (, 2023-06-07T14:31:03.317Z) OS version: Darwin arm64 22.5.0 Modes: <details<summarySystem Info</summary </details<details<summaryExtensions (12)</summaryExtensionVersion ------ vscode-eslint2.4.0 gitlens13.6.0 prettier-vscode9.13.0 copilot1.88.132 vscode-graphql0.8.13 vscode-graphql-syntax1.2.0 symbols0.0.11 vscode-react-native1.11.0 vscode-thunder-client2.7.6 vscode-fileutils3.10.1 vim1.25.2 quokka-vscode1.0.543 (1 theme extensions excluded) </details<!-- generated by issue reporter --
full text search doesn't reveal the context key anymore. Has that been removed/renamed?
It is
sorry I was writing that instead of copy-pasting. Already updated the issue.
Does it work when you swap the keybinding configurations? (Like literally exchange the positions in the file)
Still the same issue even if I swap places :(
So, its either the or context key. Can you investigate with the F1 Inspect Context Key Tools to see if those context keys are set. Note that it will print context keys on the console of DevTools
<details<summaryContext keys</summary</details
as you can see is and is , but even though inline suggest was visible it returned false.
Same in the monaco, if the suggest widget is visible, the inlineSuggestWidgetVisible will always be false no matter there is any ghost text or not
<!-- AUTHORVERIFICATIONREQUEST --This bug has been fixed in the latest release of ! you can help us out by commenting if things are now working as expected.
If things still don't seem right, please ensure you're on version of Insiders (today's or later - you can use in the command palette to check), and leave a comment letting us know what isn't working as expected. Happy Coding!
Now I see us hiding the suggest widget first and the inline suggest second, is that expected? This is true regardless of what order I declare the keybindings in (I do have the Vim extension installed)
It should hide first inline suggestions and second time you press it, it should hide suggest widget. Try to swap places of keybindings to see if it fixes it (order maybe matters?). Because previously this is how it worked (in 1.78, but regression was introduced in 1.79). EDIT: Oh I see you mentioned that order doesn't matter. Try to add in clause for command (I hope it works).
is it fixed for you on the latest insider builds The following does not work for me either
It works! !
Great, thanks for confirming!
VSCode freeze on mouse wheel scrolling with lot of tests: open test explorer, ! right-click on the test button scroll tests with mouse wheel at least twice VS Code version: Code - Insiders 1.64.0-insider (, 2021-12-22T05:15:27.690Z) OS version: Linux x64 5.4.0-92-generic Restricted Mode: No <details<summarySystem Info</summary </details<details<summaryExtensions (20)</summaryExtensionVersion ------ vscode-eslint2.2.2 gitlens-insiders2021.12.2804 EditorConfig0.16.4 prettier-vscode9.0.0 themeswitch1.0.5 rpm-spec0.3.2 vscode-docker1.18.0 python2022.0.-dev vscode-pylance2021.12.3-pre.1 jupyter2022.1. jupyter-keymap1.0.0 jupyter-renderers1.0.4 remote-containers0.209.6 remote-ssh0.70.0 remote-ssh-edit0.70.0 code-stats-vscode1.0.18 code-spell-checker2.0.14 code-spell-checker-russian2.0.2 cron-explained1.3.1 material-theme3.13.8 </details<details<summaryA/B Experiments</summary</details<!-- generated by issue reporter --
Looks like doesn't help.
Thanks (again) for the issue!
Reminded of this by We currently have a context key (when clause) for the run menu (in the main menu). This means we don't know if the menu should be displayed on startup because it depends on extensions. The Terminal menu also has a context key but resolves very quickly so there is no delay. Should we remove both of these when clauses in favor of keeping them around with possibly disabled menu items. E.g. The "Install additional debuggers" entry should still be shown in the run menu if no current contexts are available.
Assigning to who now owns the Debug UI. Rob let me know if I can help here.
Which menu are you talking about? How is the context menu involved?
Context Menu should have been Context Key. Sorry about that, I'll edit the original post.
Looks like has decided to go this route with the Terminal menu, so I think we should align here too.
So the terminal menu will be shown all the time in web? That's what will happen with Run. I guess it will show "Install additional debuggers" And should other items be disabled or missing? They currently use so are missing. It would look like this <img width="245" alt="image" src="https://user-"I'm fine with that if it's consistent. Sort of gives false hope about what you're going to find, though
Actually, if the Run menu doesn't have a when clause, but all the subitems do and it is false, then the Run menu still doesn't show up. Would that be ok or is that still slow?
Won't install additional debuggers always be visible?
It currently has a when clause to only show up when other debuggers are present, it would only show up if I remove that. And I think "install additional debuggers" usually won't give the user what they want.
I see that entry as a way for users to discover how to get our web-based code execution extensions like Python. Maybe the text is not right? We could even have a web specific entry that filters the extension list to web-supported debuggers instead of all?
Yeah, I think that when those exist we should think about what the onramp looks like. For now I'll remove the when clause on the Run menu if you think that's the right thing to do.
sounds good, thank you
Ok, this actually isn't working the way I thought it did, and the result is that the Run menu never shows, at all. I must have tested it wrong, maybe you have to restart vscode for native menu changes to take full effect? The current state is that the Run menu has no when clause, and every command inside the menu does have a when clause. But the result seems to be: If the menu doesn't have a when clause, but initially doesn't have any enabled commands inside it, then it doesn't appear and will never appear, even if the commands inside it later get their when clauses flipped to true. The only way to get it to conditionally appear is to add a when clause to the menu itself. Does that sound like a menu bug But also I can just go back to having "Install additional debuggers" enabled all the time, I think that's fine.
that very well could be a menu bug. but thinking about it, I think having the one item always in the menu is necessary because otherwise we still result in the behavior where we don't know for some time on startup whether to show the menu or not which causes flickering.
is it expected that all of these items in the run menu are active in web? <img width="163" alt="image" src="https://user-"
You probably have some extension enabled for web which claims it can debug
Mock Debug and Python, thanks
Testing microsoft/vscode-python Following the steps, I first used the auto-generated launch configuration. This meant that it didn't exist in the I then repeated the steps by clicking the gear to create it in the the dropdown now has 2 entries with duplicate titles. I would expect that the non-file-backed configuration just disappears now that we use a Not sure if this is extension specific or the responsibility of core.
How did you trigger second time to get the dynamic one? after creating the After, , i don't see the debug welcome screen.
Using one of these methods
Thanks for the bug report. VSCode handles the auto debug configuration behavior, so I'll transfer the issue to their repository.
This still repros: ! Steps: with no file open, show all automatic: ! python -Get expected error: ! one shows up... great... now pick : ! hit the on : ! See two: !
Additionally... maybe a different issue, I noticed that if I do this: with no file open, show all automatic: ! python -Get expected error: ! one shows up... great... now pick : ! Hit to get rid of the quick pick: ! is still selected in the ! and the only way to get back to the Picker I escaped out of is to choose a different launch config in the drop down and then select again. Seems a bit odd. I would have expected the play button to give me the picker or selecting even if it's already chosen to re-trigger the picker.
I fixed a different issue... I removed the duplicate from the quick pick, but not from the debug sidebar dropdown. Same data source, I think the dropdown just needs something else to refresh it.
Handling these dynamic configs is tricky - the way they are represented, they look mostly the same as a real launch config with the same name, and there is probably another case where we fail to tell the difference
Following the steps, I now get 2 different titles but still very similar. Not sure if this is breaking any checks that you do <img width="212" alt="image" src="https://user-"
How did you get without the ? I tried again and don't see that.
Is that the name in your I have and <img width="173" alt="image" src="https://user-"and I'm not sure how to get a different name in the saved config.
That is what was generated in my launch config, yes, I did not create it manually. I am on Windows.
I can't repro it. If you want, you can show me. But, if this happens somehow, I don't think I can improve the situation anyway, because two configs with different names are just two different configs.
I still managed to repro using SteVen's original steps in this issue <img width="248" alt="image" src="https://user-"
I can't repro the issue, are you sure you didn't end up with duplicate entries in If not can you open the quick access for and share a screenshot? Or just call me sometime so I can try?
This issue has been closed automatically because it needs more information and has not had recent activity. See also our guidelines. Happy Coding!
<!-- Do you have a question? Please ask it on For bug reports, please fill in the details below. For feature requests, please describe the desired feature. --<!-- Use Help Report Issue to prefill these. --- VSCode Version: 1.23.1 OS Version: Windows 10 Enterprise Ver.1703 build .877 Im trying action. but, this action working only absolute path. is working code (absolute path) ex: - Emmet: Update Image size -not working code (root relative path) ex: - Emmet: Update Image size -its not working... <!-- Launch with to check. --Does this issue occur when all extensions are disabled?: No
Thanks for reporting PRs are welcome to fix this issue. The code behind this feature is at
Hi, I'm interested in this bug. I noticed the person filing the bug gives as a example of a working path. I believe that path means that in the current working directory there should be folder called that has another folder named which has photo in it. However, is given as an example of the command not working. It is true that this path doesn't work but I believe that is intentional. at the beginning means it starts at the root and because of that it may be looking for in a different spot in the directory. For example, if my absolute path to a image is like this: and the location to the html file being editing is in here: I can't run the command with this code: But I can run it on this: and this: Hopefully this information is useful.
Thanks for the detailed analysis I can confirm your findings. Can you share what your folder structure is? Unless folder is directly under root, we cannot expect the command to work on Also see
thx comments. I can be submitted sample folder structure. Sample folder structure is working code of path: is not working code of path but, code is Ctrl + LClick (img Preview) is working. because I think passed root path of VSCode.
Are you on Windows, Linux or Mac?
Windows
Ctrl+Click will navigate to the image file in the first 2 cases as expected in both Mac and Windows The works on all 3 cases in Mac, but only the first case in Windows. So, at the very least, we can look into if we can get the second case working to keep the experience consistent between the Ctrl+Click and the Emmet experience
<!-- Do Not Delete This! bugreporttemplate --<!-- Please read our Rules of Conduct: --<!-- Read our guide about submitting issues: --<!-- Search existing issues to avoid creating duplicates. --<!-- Test using the latest Insiders build to see if your issue has already been fixed: --<!-- Instead of creating your report here, use 'Report Issue' from the 'Help' menu in VS Code to pre-fill useful information. --<!-- Launch with to check. --Does this issue occur when all extensions are disabled?: Yes/No <!-- If you answered No above, use 'Help: Start Extension Bisect' from Command Palette to try to identify the cause. --<!-- Issues caused by an extension need to be reported directly to the extension publisher. The 'Help Report Issue' dialog can assist with this. --- VS Code Version: 1.74.2 OS Version: Ubuntu 22.04 LTS (with all updates applied) Steps to Reproduce: in using a Active Directory account (Ubuntu must be joined into an Active Directory Domain) Visual Studio Code Terminal tab, click on [ + ] sign to open a new terminal, choosing zsh. A empty terminal tab opens and no shell is launched When I look in Output tab, section 'Shared', the following log lines were found By looking at message, it seems vscode is looking at /etc/passwd for some reason. And it may be failing because when I log in with an Active Directory account, no /etc/passwd entry is created for my user, because sssd/realm does not write entries on that. I opened a terminal Window and grab the following output for helping debugging:
Looks like we need to try catch here:
<!-- AUTHORVERIFICATIONREQUEST --This bug has been fixed in the latest release of ! you can help us out by commenting if things are now working as expected. If things still don't seem right, please ensure you're on version of Insiders (today's or later - you can use in the command palette to check), and leave a comment letting us know what isn't working as expected. Happy Coding!
Verified by code review (but would still appreciate your
I confirmed now that it´s working as expected. Nice job from team! <img width="1009" alt="image" src="https://user-"
<!-- Do Not Delete This! bugreporttemplate --<!-- Please read our Rules of Conduct: --<!-- Read our guide about submitting issues: --<!-- Search existing issues to avoid creating duplicates. --<!-- Test using the latest Insiders build to see if your issue has already been fixed: --<!-- Instead of creating your report here, use 'Report Issue' from the 'Help' menu in VS Code to pre-fill useful information. --<!-- Launch with to check. --Does this issue occur when all extensions are disabled?: Yes <!-- If you answered No above, use 'Help: Start Extension Bisect' from Command Palette to try to identify the cause. --<!-- Issues caused by an extension need to be reported directly to the extension publisher. The 'Help Report Issue' dialog can assist with this. --- VS Code Version: 1.7.2 OS Version: windows Steps to Reproduce: a file with error on `cue: line has an error" settings the cursor to there
Thanks for creating this issue! It looks like you may be using an old version of VS Code, the latest stable release is 1.73.1. Please try upgrading to the latest version and checking whether this issue remains. Happy Coding!
it still occurs with 1.73.1
yeah I can reproduce this issue. is this expected?
This is not expected. Sounds should be played when cursor is navigated to the error line. worked on this initially and might have more details
I also have the same problem, but this only occurs in the insider version, I have the latest version and no sound is played Issue:
They play in OSS, but not insider's. any idea why that would be?
if that is the case then it is probably related to code bundling. Does that sound play when you F1 list audio cues?
It does play when I list audio cues in both OSS and insider's.
It also plays for terminal quick fixes - suggesting there's a bug in because I can also repro it not playing for other line feature types
This has been working for me lately, though it was definitely broken at one pt.
I have set to I navigate to a line with an error-squiggle but there is no sound being played
Issue Type: <bFeature Request</bI never used the "Contributions" tab in extensions, thinking it was for recent github contributions to the extension. I accidentially pressed it once, and found it very useful. I think the name "Contributions" is confusing and that "Details", "Internals" , "Technical Details", or something similar would make it much clearer. VS Code version: Code 1.41.1 (, 2019-12-18T15:04:31.999Z) OS version: Linux x64 5.4.14-200.fc31.x86_64 <!-- generated by issue reporter --
These are in fact contributions to VS Code. How about ?
<!-- -96bd-47a8-a0e8- --This feature request is now a candidate for our backlog. The community has 60 days to upvote the issue. If it receives 20 upvotes we will move it to our backlog. If not, we will close it. To learn more about how we handle feature requests, please see our . Happy Coding!