Broken API usage of latest WSL "No cache object found" #3797
Comments
|
I added this "enabledApiProposals": [
"extensionRuntime",
"extensionsAny"
]to
and ran CTRL + SHIFT + P -> Reset CMake Tools Extension ... And it works! |
|
@mortenfc Does this also happen in the official release version? It'd be great if you could find what version this started happening on to help us investigate. Thanks! |
|
Also, we have never supported |
|
My guess is that this is a change in the WSL extension, and either it's a bug with that extension, or a breaking change that we need to adapt to in our extension, but it requires more investigation. I currently do not think that it is a regression in the most recent release |
v-frankwang
added
more info needed
|
I tried the 3 latest versions of cmake-tools, 2 of which were stable releases. I didn't change wsl version, so I assume it's s thing for latest wsl (v0.88.2 # Settings apply across all Linux distros running on WSL 2
# https://learn.microsoft.com/en-us/windows/wsl/wsl-config#wslconfig
[wsl2]
memory=56GB
processors=18
# Specify a custom Linux kernel to use with your installed distros. The default kernel used can be found at https://github.com/microsoft/WSL2-Linux-Kernel
kernel=\\wsl.localhost\Ubuntu-22.04\boot\vmlinuz-5.15.153.1-microsoft-standard-WSL2+
# Disable page reporting so WSL retains all allocated memory claimed from Windows and releases none back when free
pageReporting=true
# Turn on default connection to bind WSL 2 localhost to Windows localhost. Setting is ignored when networkingMode=mirrored
localhostforwarding=true
autoProxy=true
firewall=false
vmIdleTimeout=600000 #ms 600 s = 10 min
; # Enable experimental features
[experimental]
sparseVhd=true
autoMemoryReclaim=gradual |
|
To be clear, the outcome was the same for last few releases of cmake-tools |
|
After I installed the extension WSL, vscode prompted me to install Ubuntu on a windows machine, can you provide a more detailed step-by-step so that we can reproduce the issue. |
|
Just install wsl with ubuntu 22.04 on windows 11, there are guides online. Open wsl through extension in vscode on windows, have some cmake project with a preset. Use wsl ext v0.88.2. Configure the preset with cmd line then try to configure with the cmake-tools extension. Then check vscode output tab -> select Extension Host (Remote) |
|
@chrmarti @lramos15 @eleanorjboyd Pinging you all because you have recently contributed to the WSL extension. We believe this issue should be transferred to the WSL extension. Thanks! |
@gcampbell-msft This looks like you might be calling I suggest to check where this happens and avoid stringifying the extension context. |
|
@chrmarti For my knowledge going forward, were you able to reproduce this yourself and this is where your call stack is from? I mainly ask so that if I implement a test fix, is it possible for me to send it your way to test? Thanks for your help and for the information. |
|
We have a ton of cmake targets (and thus .jsons created from the preset?) so this might be an issue isolated to very big projects, I don't know. ⋊> ~/r/m/b/g/.c/a/v/reply on change-VIK-7689 ↑ pwd 14:16:26
/home/mfjordchris/repos/microsar-adaptive/build/gcc7_linux_x86_64/.cmake/api/v1/reply
⋊> ~/r/m/b/g/.c/a/v/reply on change-VIK-7689 ↑ count ./* 14:16:30
2209
⋊> ~/r/m/b/g/.c/a/v/reply on change-VIK-7689 ↑ du -h ../reply 14:16:31
34M ../reply |
@gcampbell-msft This is the stack from the original report at the top of this issue by @mortenfc. |
|
@mortenfc @chrmarti @mfjordchris Could you all provide a sample project that this reproduces with? I tried to reproduce this with the WSL extension, and it doesn't seem to reproduce. Thanks |
|
@chrmarti Do you think that the change in this PR: #3880 would resolve this issue? @mortenfc Could you try this zip (change to .vsix before installing) and see if it fixes it? |
|
@gcampbell-msft Yes, from what I see! |
|
It's a big internal repo with a crap ton of jsons created from the presets. I wouldn't know how to reproduce with an open source. I'll try the new version and see if I get the problem again :) |
|
before the change (latest release): After the change (latest pre-release): |
|
@gcampbell-msft So the new release fixed something most likely! |
|
@mortenfc We have attempted to verify this issue on CMake tools: v1.19.45, but we don't have detailed reproduction steps to reproduce it. Are you able to go and verify that the issue is fixed? |
|
I just installed 1.19.49 from marketplace and ran configure and it succeeded. Maybe there is a Cache Object now, and before it would try to stringify when that uncaught error happened. |
Brief Issue Summary
Fails to configure. Gets stuck loading .jsons from the .cmake folder.
WSL remote extension host shows the reason:
cmake build output:
And then nothing
CMake Tools Diagnostics
{ "os": "linux", "vscodeVersion": "1.89.1", "cmtVersion": "1.19.0", "configurations": [ { "folder": "/home/mfjordchris/repos/microsar-adaptive", "cmakeVersion": "unknown", "configured": false, "generator": "unknown", "usesPresets": false, "compilers": {} } ], "cpptoolsIntegration": { "isReady": false, "hasCodeModel": false, "activeBuildType": "", "buildTypesSeen": [], "requests": [], "responses": [], "partialMatches": [], "targetCount": 0, "executablesCount": 0, "librariesCount": 0, "targets": [] }, "settings": [ { "communicationMode": "automatic", "useCMakePresets": "auto", "configureOnOpen": null } ] }Debug Log
Additional Information
This used to work, I guess one party broke backwards compatibility with the other.
WSL:
The text was updated successfully, but these errors were encountered: