search

microsoft / vscode-cmake-tools

CMake integration in Visual Studio Code
https://marketplace.visualstudio.com/items?itemName=vector-of-bool.cmake-tools
MIT License
1.46k stars 449 forks source link

Broken API usage of latest WSL "No cache object found" #3797

Closed mortenfc closed 2 months ago

mortenfc commented 4 months ago

Brief Issue Summary

Fails to configure. Gets stuck loading .jsons from the .cmake folder. WSL remote extension host shows the reason:

2024-05-29 10:32:12.193 [error] Error: Extension 'ms-vscode.cmake-tools' CANNOT use API proposal: extensionRuntime.
Its package.json#enabledApiProposals-property declares: [] but NOT extensionRuntime.
 The missing proposal MUST be added and you must start in extension development mode or use the following command line switch: --enable-proposed-api ms-vscode.cmake-tools
    at y (/home/mfjordchris/.vscode-server/bin/dc96b837cf6bb4af9cd736aa3af08cf8279f7685/out/vs/workbench/api/node/extensionHostProcess.js:143:51558)
    at get extensionRuntime [as extensionRuntime] (/home/mfjordchris/.vscode-server/bin/dc96b837cf6bb4af9cd736aa3af08cf8279f7685/out/vs/workbench/api/node/extensionHostProcess.js:161:12748)
    at JSON.stringify (<anonymous>)
    at RollbarController.exception (/home/mfjordchris/.vscode-server/extensions/ms-vscode.cmake-tools-1.19.0/dist/main.js:68089:60)
    at /home/mfjordchris/.vscode-server/extensions/ms-vscode.cmake-tools-1.19.0/dist/main.js:68133:38

cmake build output:

[cache] Parsing CMake cache string
[cmakefileapi-parser] Read reply folder: /home/mfjordchris/repos/microsar-adaptive/build/gcc7_linux_x86_64/.cmake/api/v1/reply
[cmakefileapi-parser] Found index files: [ 
.... tons of jsons ....
]

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

[main] Starting new CMake driver
[main] Starting CMake driver
[cmakefileapi-driver] Creating instance of CMakeFileApiDriver
[driver] Initializing base driver using preset
[driver] CMakeDriver configure preset set to gcc7_linux_x86_64
[driver] CMakeDriver build preset set to __defaultBuildPreset__
[driver] CMakeDriver test preset set to __defaultTestPreset__
[driver] CMakeDriver package preset set to __defaultPackagePreset__
[driver] CMakeDriver workflow preset set to __defaultWorkflowPreset__
[cache] Reading CMake cache file /home/mfjordchris/repos/microsar-adaptive/build/gcc7_linux_x86_64/CMakeCache.txt
[cache] Parsing CMake cache string
[cache] Reading CMake cache file /home/mfjordchris/repos/microsar-adaptive/build/gcc7_linux_x86_64/CMakeCache.txt
[cache] Parsing CMake cache string
[cmakefileapi-parser] Read reply folder: /home/mfjordchris/repos/microsar-adaptive/build/gcc7_linux_x86_64/.cmake/api/v1/reply
[cmakefileapi-parser] Found index files: ["codemodel-v2-9c7b1a5b13e6cd7abb21.json","directory-.-Debug-ef777644173ec83da69e.json", ... and a ton of other jsons that would exceed github character limit ... ]
[extension] [7571] cmake.logDiagnostics finished (returned undefined)

Additional Information

This used to work, I guess one party broke backwards compatibility with the other. WSL:

[2024-05-29 08:32:02.502] Using executable (49) to forward requests from local 54579 to remote 42613
[2024-05-29 08:32:02.502] NodeExecServer run: C:\Windows\System32\wsl.exe -d Ubuntu-22.04 -e /home/mfjordchris/.vscode-server/bin/dc96b837cf6bb4af9cd736aa3af08cf8279f7685/node -e const net = require('net'); process.stdin.pause(); const client = net.createConnection({ host: '127.0.0.1', port: 42613 }, () => { client.pipe(process.stdout); process.stdin.pipe(client); }); client.on('close', function (hadError) { console.error(hadError ? 'Remote close with error' : 'Remote close'); process.exit(hadError ? 1 : 0); }); client.on('error', function (err) { process.stderr.write(err && (err.stack || err.message) || String(err)); });
[2024-05-29 08:32:01.745] Extension version: 0.88.2
[2024-05-29 08:32:01.745] L10N bundle: undefined
[2024-05-29 08:32:01.782] authorityHierarchy: wsl+Ubuntu-22.04
[2024-05-29 08:32:01.782] WSL extension activating for a local WSL instance
[2024-05-29 08:32:01.803] Resolving wsl+Ubuntu-22.04, resolveAttempt: 1
[2024-05-29 08:32:01.804] NodeExecServer run: C:\Windows\System32\wsl.exe --status
[2024-05-29 08:32:01.965] WSL feature installed: true (wsl --status)
[2024-05-29 08:32:01.965] NodeExecServer run: C:\Windows\System32\wsl.exe --list --verbose
[2024-05-29 08:32:02.096] 1 distros found
[2024-05-29 08:32:02.096] Starting VS Code Server inside WSL (wsl2)
[2024-05-29 08:32:02.096] Windows build: 22621. Multi distro support: available. WSL path support: enabled
[2024-05-29 08:32:02.097] Scriptless setup: false
[2024-05-29 08:32:02.098] No shell environment set or found for current distro.
[2024-05-29 08:32:02.239] WSL daemon log file: c:\Users\mfjordchris\AppData\Roaming\Code\logs\20240528T164619\window3\exthost\ms-vscode-remote.remote-wsl\wsl-daemon-20240529T083202.log
[2024-05-29 08:32:02.244] Connecting to daemon started by other WSL window... 5.15.146.1-microsoft-standard-WSL2 Ubuntu-22.04
[2024-05-29 08:32:02.244] WSL resolver response: 127.0.0.1:54579
[2024-05-29 08:32:02.244] To debug connection issues, open a local browser on http://127.0.0.1:54579/version
[2024-05-29 08:32:02.244] No extension host environment set
[2024-05-29 08:32:02.331] Using executable (48) to forward requests from local 54579 to remote 42613
[2024-05-29 08:32:02.332] NodeExecServer run: C:\Windows\System32\wsl.exe -d Ubuntu-22.04 -e /home/mfjordchris/.vscode-server/bin/dc96b837cf6bb4af9cd736aa3af08cf8279f7685/node -e const net = require('net'); process.stdin.pause(); const client = net.createConnection({ host: '127.0.0.1', port: 42613 }, () => { client.pipe(process.stdout); process.stdin.pipe(client); }); client.on('close', function (hadError) { console.error(hadError ? 'Remote close with error' : 'Remote close'); process.exit(hadError ? 1 : 0); }); client.on('error', function (err) { process.stderr.write(err && (err.stack || err.message) || String(err)); });
[2024-05-29 08:32:02.798] Download in background is enabled
mortenfc commented 4 months ago

I added this 

    "enabledApiProposals": [
        "extensionRuntime",
        "extensionsAny"
    ]

to

/home/mfjordchris/.vscode-server/extensions/ms-vscode.cmake-tools-1.19.0

and ran

CTRL + SHIFT + P -> Reset CMake Tools Extension ...

And it works!

gcampbell-msft commented 4 months ago

@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!

gcampbell-msft commented 4 months ago

Also, we have never supported extensionRuntime as a enabledApiProposal in our package.json. Did this work in previous versions?

gcampbell-msft commented 4 months ago

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

mortenfc commented 4 months ago

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 image ), or how I have it configured in my .wslconfig:

# 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
mortenfc commented 4 months ago

To be clear, the outcome was the same for last few releases of cmake-tools

v-frankwang commented 3 months ago

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.

mfjordchris commented 3 months ago

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 cmake -S . --preset=preset_name

then try to configure with the cmake-tools extension.

Then check vscode output tab -> select Extension Host (Remote)

gcampbell-msft commented 3 months ago

@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!

chrmarti commented 3 months ago

Fails to configure. Gets stuck loading .jsons from the .cmake folder. WSL remote extension host shows the reason:

2024-05-29 10:32:12.193 [error] Error: Extension 'ms-vscode.cmake-tools' CANNOT use API proposal: extensionRuntime. Its package.json#enabledApiProposals-property declares: [] but NOT extensionRuntime. The missing proposal MUST be added and you must start in extension development mode or use the following command line switch: --enable-proposed-api ms-vscode.cmake-tools at y (/home/mfjordchris/.vscode-server/bin/dc96b837cf6bb4af9cd736aa3af08cf8279f7685/out/vs/workbench/api/node/extensionHostProcess.js:143:51558) at get extensionRuntime [as extensionRuntime] (/home/mfjordchris/.vscode-server/bin/dc96b837cf6bb4af9cd736aa3af08cf8279f7685/out/vs/workbench/api/node/extensionHostProcess.js:161:12748) at JSON.stringify () at RollbarController.exception (/home/mfjordchris/.vscode-server/extensions/ms-vscode.cmake-tools-1.19.0/dist/main.js:68089:60) at /home/mfjordchris/.vscode-server/extensions/ms-vscode.cmake-tools-1.19.0/dist/main.js:68133:38

@gcampbell-msft This looks like you might be calling JSON.stringify on something that references the vscode.ExtensionContext object and JSON.stringify hits the proposed API behind extensionRuntime (https://github.com/microsoft/vscode/blob/85e9b0786cc505d85f326991227de364a5bd7293/src/vscode-dts/vscode.proposed.extensionRuntime.d.ts#L22).

I suggest to check where this happens and avoid stringifying the extension context.

gcampbell-msft commented 3 months ago

@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.

mfjordchris commented 3 months ago

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
chrmarti commented 3 months ago

@chrmarti For my knowledge going forward, were you able to reproduce this yourself and this is where your call stack is from?

@gcampbell-msft This is the stack from the original report at the top of this issue by @mortenfc.

gcampbell-msft commented 2 months ago

@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

gcampbell-msft commented 2 months ago

@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? cmake-tools.zip

chrmarti commented 2 months ago

@gcampbell-msft Yes, from what I see!

mortenfc commented 1 month ago

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 :)

mortenfc commented 1 month ago

before the change (latest release):

2024-08-07 17:58:30.458 [error] Error: Extension 'ms-vscode.cmake-tools' CANNOT use API proposal: extensionRuntime.
Its package.json#enabledApiProposals-property declares: [] but NOT extensionRuntime.
 The missing proposal MUST be added and you must start in extension development mode or use the following command line switch: --enable-proposed-api ms-vscode.cmake-tools
    at P (/home/mfjordchris/.vscode-server/bin/b1c0a14de1414fcdaa400695b4db1c0799bc3124/out/vs/workbench/api/node/extensionHostProcess.js:142:59143)
    at get extensionRuntime [as extensionRuntime] (/home/mfjordchris/.vscode-server/bin/b1c0a14de1414fcdaa400695b4db1c0799bc3124/out/vs/workbench/api/node/extensionHostProcess.js:160:12849)
    at JSON.stringify (<anonymous>)
    at RollbarController.exception (/home/mfjordchris/.vscode-server/extensions/ms-vscode.cmake-tools-1.18.44/dist/main.js:95682:60)
    at /home/mfjordchris/.vscode-server/extensions/ms-vscode.cmake-tools-1.18.44/dist/main.js:95726:38

After the change (latest pre-release):

2024-08-07 18:00:26.131 [warning] [redhat.java] Accessing a resource scoped configuration without providing a resource is not expected. To get the effective value for '[java]', provide the URI of a resource or 'null' for any resource.
2024-08-07 18:00:28.770 [error] TypeError: Converting circular structure to JSON
    --> starting at object with constructor 'Object'
    |     property 'configurePresets' -> object with constructor 'Array'
    |     index 0 -> object with constructor 'Object'
    --- property '__file' closes the circle
    at JSON.stringify (<anonymous>)
    at RollbarController.exception (/home/mfjordchris/.vscode-server/extensions/ms-vscode.cmake-tools-1.19.37/dist/main.js:113370:60)
    at /home/mfjordchris/.vscode-server/extensions/ms-vscode.cmake-tools-1.19.37/dist/main.js:113414:38
mortenfc commented 1 month ago

@gcampbell-msft So the new release fixed something most likely! Sorry for not being more responsive. I'll be quicker to test future versions if you solve this also

v-frankwang commented 1 month ago

@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?

mortenfc commented 3 weeks ago

I just installed 1.19.49 from marketplace and ran configure and it succeeded. I then tried 1.18.44 and it also succeeded 🤷 I guess something in my cmake setup changed.

Maybe there is a Cache Object now, and before it would try to stringify when that uncaught error happened.