VSCode usuable after update

1

After updating NixOS Unstable (see the packages affected)

image
image925×377 51.2 KB

VSCode launches with big, wide visual artifacts making it unsuable. Logs tell me that the X server keeps dying, among other things:

déc 11 17:53:57 nixos systemd-coredump[4844]: Process 4382 (chrome_crashpad) of user 1000 dumped core.
                                               
                                               Module libgcc_s.so.1 without build-id.
                                               Stack trace of thread 4383:
                                               #0  0x0000560b7a7f2024 n/a (chrome_crashpad_handler + 0x46024)
                                               #1  0x0000560b7a7f37ce n/a (chrome_crashpad_handler + 0x477ce)
                                               #2  0x0000560b7a88ab27 n/a (chrome_crashpad_handler + 0xdeb27)
                                               #3  0x0000560b7a7f9222 n/a (chrome_crashpad_handler + 0x4d222)
                                               #4  0x0000560b7a7f9b9d n/a (chrome_crashpad_handler + 0x4db9d)
                                               #5  0x0000560b7a7f67a7 n/a (chrome_crashpad_handler + 0x4a7a7)
                                               #6  0x0000560b7a7f6526 n/a (chrome_crashpad_handler + 0x4a526)
                                               #7  0x0000560b7a7f6236 n/a (chrome_crashpad_handler + 0x4a236)
                                               #8  0x0000560b7a85b5a4 n/a (chrome_crashpad_handler + 0xaf5a4)
                                               #9  0x0000560b7a85d869 n/a (chrome_crashpad_handler + 0xb1869)
                                               #10 0x00007f9ee0901084 start_thread (libc.so.6 + 0x8b084)
                                               #11 0x00007f9ee098360c __clone3 (libc.so.6 + 0x10d60c)
                                               
                                               Stack trace of thread 4384:
                                               #0  0x00007f9ee08fdc96 __futex_abstimed_wait_common (libc.so.6 + 0x87c96)
                                               #1  0x00007f9ee0908b0b __new_sem_wait_slow64.constprop.0 (libc.so.6 + 0x92b0b)
                                               #2  0x0000560b7a85d5ca n/a (chrome_crashpad_handler + 0xb15ca)
                                               #3  0x0000560b7a85b582 n/a (chrome_crashpad_handler + 0xaf582)
                                               #4  0x0000560b7a85d869 n/a (chrome_crashpad_handler + 0xb1869)
                                               #5  0x00007f9ee0901084 start_thread (libc.so.6 + 0x8b084)
                                               #6  0x00007f9ee098360c __clone3 (libc.so.6 + 0x10d60c)
                                               
                                               Stack trace of thread 4382:
                                               #0  0x00007f9ee0983a26 epoll_wait (libc.so.6 + 0x10da26)
                                               #1  0x0000560b7a7f4341 n/a (chrome_crashpad_handler + 0x48341)
                                               #2  0x0000560b7a7f1719 n/a (chrome_crashpad_handler + 0x45719)
                                               #3  0x0000560b7a7e6494 CrashpadHandlerMain (chrome_crashpad_handler + 0x3a494)
                                               #4  0x00007f9ee089dfce __libc_start_call_main (libc.so.6 + 0x27fce)
                                               #5  0x00007f9ee089e089 __libc_start_main@@GLIBC_2.34 (libc.so.6 + 0x28089)
                                               #6  0x0000560b7a7dc0ca _start (chrome_crashpad_handler + 0x300ca)
                                               ELF object binary architecture: AMD x86-64
(snip)
déc 11 17:51:00 nixos .gnome-shell-wr[1321]: Xwayland terminated, exiting since it was mandatory
déc 11 17:51:00 nixos .gnome-shell-wr[1321]: Connection to xwayland lost
(snip)

I am reluctant to report a bug against Nixpkgs as VSCode doesn’t seem to be the culprit. Any suggestion on how to proceed?

2 Likes
2

Delete it’s GPUCache in its config folder.

Where exactly this is, depends on the exact version used (insider, regular, sodium, etc)

2 Likes
3

Holly cow! It worked. How did you know? I am flabbergasted by the contrast between how serious the logs looked like and how trivial your fix is.

1 Like
5

I do this every month. And am close to just integrating the deletion of GPUcache into my regular update flow

2 Likes
6

This also worked for me; I was getting strange pixel flickering or whatnot after an update. Hot tip!

7

In the Year of Linux on the Desktop :slight_smile:

8

Why do we need to do it suddenly? I had to delete GPUCache for Chrome and Element recently.

9

I have no clue.

Following nixos-unstable on my system, I had to start with the regular deletion of the GPUCache during summer. I definitely didn’t have that problem before May, though I am not sure when exactly it started.

I can say though from discussions in the inofficial Discord, that there have been poeple that had the problem before I had it.

1 Like
10

How do I do that for brave, this happens for me with brave too… There is no GPUCache Folder for Brave.

11

There is, its just hidden elsewhere.

Everything that uses chromium based rendering has that gpu-cache folder somewhere.

1 Like
12

Update, yes I just found it.

It’s in BraveSoftware/Brave-Browser/Default/

But that’s really strange… I even tried different channels and all of them seem to have an update causing this issue?!