jiebi/CodeConvo huggingface dataset:
<!-- 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. --- VS Code Version: 1.50 OS Version: Windows 10 and Mac OSX Catalina Steps to Reproduce: to a remote server the remote server's extension host to crash, possibly by running out of memory or by killing the process yourself. the remote server's extension host has crashed, attempt to file a bug by clicking the bug nub icon in the bottom right corner of the main window. Expected Result: Issue reporter window appears and allows user to file a bug Actual Result: Issue reporter window fails to launch. If you check the debugger, you will see that an exception stack trace for "ExtensionManagementService.getInstalled". Since the remote extension host is not active, doesn't work - it throws an exception rather than returning an empty list. <!-- 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 direct to the extension publisher. The 'Help Report Issue' dialog can assist with this. --
VSCode Version: Code 1.14.2 (, 2017-07-19T23:34:09.706Z) OS Version: Windows_NT ia32 10.0. Extensions: ExtensionVersion ------ cpptools0.12.1 csharp1.11.0 Steps to Reproduce: an empty folder with VSCode a new MSBuild task building (execute task) Expected: Fails gracefully somehow Actual: Just spins forever and never dies until I manually kill the task. Note: this also happens when I mistype a path or something in the command to a directory that say for example doesn't exist. If the command is wrong in some way, the task will just spin forever. <!-- Launch with to check. --Reproduces without extensions: Yes/No
The terminal doesn't send an onExit or any other event in this case so that the task system could determine that the process has finished / died. Steps to reproduce: Windows, no msbuild installed fresh workspace configure task runner select MSBuild from the list of templates F1 Run Task Select Build Observe: the spinner never stops. Could can't even terminate the task. The reason is that the shell actually fails to execute msbuild however the terminal never send an onExit event. Look at the process explorer there is a lingering vscode process of --type=terminal <img width="521" alt="capture" src="https://user-"
I upgraded to node-pty which may improve the problem, if not I'd guess this is related towinpty is not terminating the processes correctly.
I retested this and it is still happening under Insider today.
terminalProcess stalls on this native call: , meaning this function never returns Not sure why a or native exception isn't happening.
This has the same root cause as
Moving to September as this is a more involved change than I anticipated. More testing in Insiders would be ideal.
any news on this. Do I need to adopt something here ?
No progress, I moved this to September before I knew that I would be out for 2 weeks in September.
It does look like it affects Windows only.
Hmm, I believe that I just came across this while trying to run some tests, and exited with an error code. I was able to reproduce it using this: Everything works fine if the error code is changed to .
Was this never solved?
when I last tested this I had the impression that this is still a bug and the terminal hangs (doesn't signal on exit).
Yes, this is still an issue.
Is this in line to be fixed btw?
This still happens btw when I'm doing my PowerShell development.....I have to keep restarting all of VSCode because my debugging sessions won't end properly.
does this sound like something that will be fixed by conpty?
it probably needs a check in node-pty that the file exists before attempting to fire it. It's possible that conpty would fix this but that would only fix it for newer Windows versions when the fix should work when we fallback to winpty.
There's already a check in node-pty before attempting to execute the file. I can't actually reproduce this with a garbage command in my task (ex. ) I do think I'm seeing this when I pass garbage in for the that results in a failure though: 'c:usersalrosdesktop' is not recognized as an internal or external command, operable program or batch file.`
<!-- 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.58+ OS Version: Windows Steps to Reproduce: with and . the browser launches, the server throws. This is due to: It should just be . I have a PR to fix this, but needed an issue to reference.
<!-- 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. --- VS Code Version: From sources !
That looks grid related to me.
Web bisect points out this commit range which includes the move to the new table widget: This seems to require the custom menu (Windows, Web) to reproduce.
fyi, not sure if anything within the keybindings editor could have caused this other than adopting the table widget.
Can also be reproduced by focusing the search input and then tabbing until the table is focused Created a PR fixing this.
Tagged this as candidate as the experience is bad with custom menu and it is a regression. As mentioned it can also be reproduced everywhere with following steps: Open Keybindings editor Focus search input Tab until table is focused Editor title bar is not visible
I can reproduce this in my Stable VS Code 100% of the time. I can not reproduce in VS Code Insiders. Click on the Account icon in the activity bar -nothing happens Open developer tools console and notice exception
Assigning to as well, since and me investigated and it seems like the value in my KeyTar got corrupted and can no longer be JSON parsed. We tried with a fresh user data dir and we could still repro since the same KeyTar is used.
can you run this simple one-liner and tell me if you get a value?: This is using the following open source package: What you should get is something like this: If that returns a value, then I'm shocked that it did because nothing in core sets that (only embedders do this in the web)... could an embedder be writing to this on accident? If it doesn't.... that's also odd since your stacktrace is
I just ran that, and yes I get
verification: this: vscode insiders in to an account/open the account menu It shouldn't throw the error above.
<!-- Do Not Delete This! bugreporttemplate --<!-- Please read our Rules of Conduct: --<!-- Please search existing issues to avoid creating duplicates. --<!-- Also please test using the latest insiders build to make sure your issue has not already been fixed: --<!-- Use Help Report Issue to prefill these. --- VSCode Version: 1.45.1 OS Version: OS X 10.15.5 Beta Steps to Reproduce: a text file whose name is just a number, e.g. , , etc to launch the file from the command line file is opened. If VSCode was closed, it starts and just shows the welcome screen. If VSCode is running, you see another VSCode icon bounce in the dock and go away. to file to something else, it works fine <!-- Launch with to check. --Does this issue occur when all extensions are disabled?: Yes
I have a feeling we've seen this before?
yes I remember something was not right with our argv lib (minimist?) with regards to handling numbers?
Hi, was having this problem too and I think I found the cause We were discarding empty args as part of , however this would discard numbers too as they were not strings when the check took place Have made a PR to remedy this if that's ok
create a notebook and save it. Run a cell with a kernel. Change the kernel and run another cell reopen the notebook as plain text and note the kernel spec in the metadata. metadata should specify the kernel that was most recently used, but it specifies the original. Seems to repro with both local and remote kernels
impacts microsoft/vscode-jupyter since we're not getting the correct suggestion
I think this is a regression. please could you verify this works as expected in stable.
yes, the kernelspec updates in stable as expected
This is actually a bug in the new metadata API. Transferring to vscode core.
This should've been assigned to since we are adamant in verifying each issue that gets shipped in a recovery release individually. I found this out by looking into . Please find someone to verify this issue in the latest release candidate build.
Oh my bad... this was released already in ... My mistake.
But there's still a recommendation: this should've been assigned to all along so people verify the issue was fixed. Can you find someone to verify and mark it as ?
I had actually verified back when it was fixed, just didn't add the label since it wasn't marked verification needed. I'll do that now tho
Thanks!
<!-- 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: OS Version: Windows 10 -- Ref: Steps to Reproduce: theme to new terminal cursor is white on a light background which is hard to see for most I'm about 99% sure this is not associated with any customized profile in use for PowerShell session. Starting with no profile shows the same thing. !
VSCode Version: 1.34.0-insider (1.34.0-insider) OS Version: macOS mojave 10.14.4 Steps to Reproduce: in activate method of any extension. the developer tools. What is expected? Show the file dialog like following: ! What is actually happening? Following error message shown in the Developer tools. Does this issue occur when all extensions are disabled?: Yes According to the code here: , I think the reason is " is ", then I got as the of see here: If you confirm this is a bug, I'd like to create a pull request to fix it.
I think I find the commit which cause the bug, see: Here we transform the " and " to " and ", but the args that send is still , and because it send undefined in my case, I got as , then the error throws. Since I find the cause of this bug, I feel confident to create a pull request to fix it. : )
Yes, PR is welcome!
<!-- 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: OS Version: Steps to Reproduce: Python issue reporter selects (, instead of )
<!-- 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: Version: 1.81.0 (user setup) Commit: Date: 2023-08-02T12:37:13.485Z Electron: 22.3.18 ElectronBuildId: Chromium: 108.0.5359.215 16.17.1 V8: 10.8.168.25-electron.0 OS: Windows_NT x64 10.0. Steps to Reproduce: a .cpp file (or a .c file). Don't have the C/C++ Extension Pack installed. Bug: The extension recommendation popup uses text "for C++ language", which isn't grammatically correct. It's possible the same issue repros for other languages. I wasn't able to locate the source of the text (maybe it's from a private repo). ! Potential fix 1: It should use "for the C++ language" to be grammatically correct. Potential fix 2: Well, to be even more accurate, for the C/C++ extension pack, it should say "for the C and C++ languages". Potential fix 3: Or, if it can say "for the C++ language" when triggered from a "cpp" language file and a "for the C language" when triggered from a "c" language file.
can I work on this issue?
Are you able to locate where that text is coming from?
been searching the text source for some time but not able to find it. Did you find anything?