Recently I discovered that the Live Share extension on VSCode had crash dumped a bunch of times on `coredumpctl`. I started investigating the problem and found out that technically Gentoo isn't supported by MS, buy that the ebuild on the jorgicio overlay has been known to work: https://docs.microsoft.com/en-us/visualstudio/liveshare/reference/linux#tips-for-community-supported-distros Link to the `1.67.1` ebuild in the jorgicio overlay (latest available in jorgicio, as of time of this writing): https://github.com/jorgicio/jorgicio-gentoo-overlay/blob/main/app-editors/vscode-bin/vscode-bin-1.67.1.ebuild I did cross-reference our deps with the ebuild above and noticed minimal differences or missing deps. NTM most of the missing deps were already installed with the exceptions of a few (that I'll be submitting in a PR). Also, dotnet may also need to be installed. ...and while that did fix some other unrelated issues, that didn't fix this issue. After further investigating, I found that you can run .NET in 'Invariant Mode': https://docs.microsoft.com/EN-US/dotnet/core/runtime-config/globalization#invariant-mode So I created a file (`99vscode`) in `/etc/env.d/` with the contents `DOTNET_SYSTEM_GLOBALIZATION_INVARIANT=1` and that ended up fixing the problem. Regardless, that would mean that our ICU implementation is wrong? or perhaps we're missing a variable or something? Reproducible: Always
Created attachment 796717 [details] coredumpctl info 5737 Here's a sample of one of the crash dumps.
As a co-maintainer, we will gladly accept any PR - and huge thank you for investigating and working on it! About what you said with dotnet, sorry but I have hard time to understand it? Can we make it optional dep (behind use flag)? And do I understand correctly that for vscode to work without dotnet we need to define that env var?
Well, it's kinda a very interesting delimma. I did more investigating. So VSCode (the GitHub repo) DOES NOT claim to have had a `dotnet` dependency; however, the plugins (whose source code IS NOT publicly available) that are added in the MS redistributable (VSCode vs. VSCodium debacle) seem to expect to find some sort of `dotnet` runtime. That said, it's not an issue unless you're minutely reading the output logs or you start installing plugins by MS (the plugins get you in trouble fast). This brings us to our next issue. We don't have a `dotnet` runtime (https://dotnet.microsoft.com/en-us/download/dotnet/6.0). We have the SDK, which (I think) includes the runtime, but it's the kitchen sink. Perhaps a runtime ebuild would be in order, without installing the kitchen sink, as that's what it needs. That said, that runtime seems to be what most other distros are distributing with VSCode installations.
BTW some ebuilds already exist of the `dotnet` runtime. So it wouldn't be very difficult to make a solid official one. If that's what we decide, I wouldn't be opposed to drafting it myself.
Thank you for looking into all of this, PRs are always welcome ! I am not very knowledgeable with vscode's shenanigans, I looked more into the live share extension's link you gave and it gave me the same impression : it looks like that extension in particular needs the extra dependencies you brought up (I checked out what inside the "prerequisite install script" [1]). So yeah I think it will be best to put all of that behind a useflag for those who want to use the extension. [1] https://docs.microsoft.com/en-us/visualstudio/liveshare/reference/linux#install-linux-prerequisites
NP, Adel. TBF MS's shenanigans are quite interesting, or maybe that just be my thing (since I deal a lot with Linux Foundation stuff), lol. (I learned a lot about it through the VS Codium debacle that happened some years ago.) That said, VSCode does seem to look for the `dotnet` runtime, no matter what. However, it only produces a warning, not an error, when it's not found. Beyond that, I have not observed anything else that changes the expected behavior of the program. Otherwise, you are correct; the hard error (that seems to cause the dump) can only be observed only when a plugin that depends on the runtime is installed, such as Live Share.
That said, going back to the ICU problem, beyond `dotnet` runtime crash though. I did want to point out, Arch has `icu69` listed as dep for Live Share. We don't have a ebuild for `icu69`. I don't know if our `icu` ebuild suffices. Ref: https://aur.archlinux.org/packages/visual-studio-code-bin
