code-server downloads aarch64 version of C/C++ extension (cpptools) on amd64 machine

[peat-psuwit]

• Web Browser: Chromium 85.0.4183.102 snap (AKA snap chromium version 1298)
• Local OS: Ubuntu 20.04
• Remote OS: Ubuntu 20.04
• Remote Architecture: AMD64
• code-server --version: 3.5.0 de41646fc402b968ca6d555fdf2da7de9554d28a

Step to reproduce:

1. Make sure any trace of cpptools extension in ~/.local/share/code-server/{CachedExtensionVSIXs,extensions} is removed.
2. Start code-server and open a window. Install C/C++ from the extension tab and reload when requested.
3. 2 errors appeared:
   • The language server crashed 5 times in the last 3 minutes. It will not be restarted.
   • The C/C++ extension failed to install successfully. You will need to repair or reinstall the extension for C/C++ language features to function properly.
4. Clicking Attempt to Repair will reload the window, and the extension seems to download binaries for x86_64, but after that the first error still appears.

Both after step 3. and step 4, the binary from both the extracted directory and the VSIX itself shows that the binary is AArch64 instead of AMD64 (I don't know where the extension downloads binaries to):

~/.local/share/code-server/extensions/ms-vscode.cpptools-1.0.0$ file bin/cpptools
bin/cpptools: ELF 64-bit LSB executable, ARM aarch64, version 1 (GNU/Linux), dynamically linked, interpreter /lib/ld-linux-aarch64.so.1, for GNU/Linux 3.7.0, BuildID[sha1]=a6622307e0c01de448bbd8e6567e33b18d0c26c0, not stripped

The remoteagent.log is obtained at step 2, before reloading (the log level is set to trace). I manually download the extension using URL in the log (starts with https://storage.googleapis.com/vscode-extension-assets), and it contains arm64 binaries. Interestingly, I don't see any architecture parameter in the query.

Workaround: manually download the extension from extension's GitHub release page seems to work correctly. Notice that they're

the "offline" .vsix (that doesn't download OS-based dependencies on extension activation)

I suspect that the store is supposed to distribute "online" .vsix that works on all architecture?

[welljsjs]

Same here. Currently causing us a bit of a headache.

[dirkcgrunwald]

This is a big problem for us as well - we use code-server in Jupyterhub for our undergrad classes. We're using the work around (directly load the extension) but it requires each student to run a script.

[goshander]

same issue

ubuntu server 20.04.1
code-server 3.6.0

CPU 1005 after extension installation start

[dirkcgrunwald]

This is still an issue in release 3.7.2

[Error - 6:30:36 PM] Connection to server got closed. Server will not be restarted.
/home/jovyan/.local/share/code-server/extensions/ms-vscode.cpptools-1.1.2/bin/cpptools: 7: Syntax error: word unexpected (expecting ")")

and looking at the file

jovyan@jupyter-grunwald:~/.local/share/code-server/extensions$ file ms-vscode.cpptools-1.1.2/bin/cpptools
ms-vscode.cpptools-1.1.2/bin/cpptools: ELF 64-bit LSB executable, ARM aarch64, version 1 (GNU/Linux), dynamically linked, interpreter /lib/ld-linux-aarch64.so.1, for GNU/Linux 3.7.0, BuildID[sha1]=1f1d022564fe3736517f4b233ca3286638074a16, not stripped

I'm not familiar enough with the code-server code base to start digging into why this might be happening to avoid the problem in the future.

According to the log file from @peat-psuwit this appears to be trying to download an x64 binary. Is the package perhaps just improperly labeled in storage.googleapis.com?

telemetry/galleryService:downloadVSIX {"properties":{"id":"ms-vscode.cpptools","name":"cpptools","galleryId":"ms-vscode.cpptools","publisherId":"ms-vscode","publisherName":"ms-vscode","publisherDisplayName":"ms-vscode","searchText":"c++","querySource":"searchText","common.machineId":"4e9c65ed78290ec04ca403f5b329829a5567531a40ed4833b53932c50a9e36b2","sessionID":"b2b5bde1-38bb-462f-9192-b4585dce3c1c1600692524250","commitHash":"de41646fc402b968ca6d555fdf2da7de9554d28a","version":"1.48.2","common.platformVersion":"5.4.0","common.platform":"Linux","common.nodePlatform":"linux","common.nodeArch":"x64","common.product":"code-server","timestamp":"2020-09-21T12:49:10.328Z"},"measurements":{"dependencies":0,"index":0,"duration":7008,"common.timesincesessionstart":26078,"common.sequence":30}}

[code-asher]

I suspect that the store is supposed to distribute "online" .vsix that works on all architecture?

Yup, it looks like our marketplace is just uploading the first .vsix it finds in their GitHub releases which is the linux-aarch64 one.

They don't seem to distribute the "online" version there, so the ideal situation would be to have them add it to the GitHub releases so we can make use of it.

Otherwise we'll need to build it ourselves. Either that or modify our marketplace to support multiple versions of an extension then patch the extension gallery code in VS Code to download the right one based on the operating system.

[HuJK]

Any plan to fix this issue?

Like separate the repository for different arch?
Or just match the filename while download extensions if there were multiple vsix in a single release.

If we have a x86_64 linux server, it will try to download file name contains x86_64 -> x64-> amd64 -> linux(sort by len(filename)) -> unix -> other
Else if I have a arm64 linux server, it well try to download file name contains aarch64 -> arm64 -> linux(sort by len(filename)) -> unix -> `other

Instead of just download the first vsix from github releases.

[code-asher]

At the moment our plan is to switch to Open VSX which will deprecate our marketplace.

[stale]

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no activity occurs in the next 5 days.

[peat-psuwit]

Ok. The thing is, the cpptools extension's EULA actually prohibits the use with non-MS version of VSCode. Also, since code-server now uses Open-VSX registry, I'm not sure if this problem is still relevant or not. Maybe Open-VSX have a similar problem?

P.S. if someone want a C/C++ extension that is legal to use on code-server, I recommend clangd's VSCode extension. With properly configured compile_commands.json, it will work better than Microsoft's one.

[code-asher]

Excellent point, I think at least as far as code-server is concerned this issue has reached the end of its life. It seems unlikely anything can be done about this as long as the restrictive license is in play but the clangd extension seems like the perfect alternative! Thanks for linking to that.