GPU crash prevents codium from running Kubuntu 24.04 ARM in VirtualBox

[d33p-dev]

I have been using Codium for a few days without issue. Today it won't start. The GPU process crashes on startup. This is Ubuntu 24.04 ARM running in VirtualBox on MBP M1.

This VM has no GPU, 3D Acceleration is disabled. It has been since I created the VM and that's bc GPU support with VirtualBox with MacOS host is not stable apparently, so I disabled it when I was installing Ubuntu and getting it setup.

I'll check but I'm not aware of any changes I've made to either VBox or Codium since I started using Codium a few days ago in this VM. Not sure what to try at this point.

Here's the log when running codium --verbose:

[5499:0830/094504.124332:WARNING:content/browser/gpu/gpu_process_host.cc:1398] The GPU process has crashed 9 time(s) [5499:0830/094504.124342:FATAL:content/browser/gpu/gpu_data_manager_impl_private.cc:415] GPU process isn't usable. Goodbye.

[d33p-dev]

Ok I think this is what caused it / resolved it....

• Initially, after getting VirtualBox setup with Ubuntu, during the setup I had installed VBox Extensions
• This didn't seem to have any impact on VBox VM running Ubuntu
• Over several days I would turn off / shutdown the VM in VBox when I was done using it
• I would only sleep the host OS at night, not power down
• I powered down the host last night
• I believe that VBox only then loaded the Extensions into the VM after the host rebooted
• I disabled Extensions, rebooted the host and then Codium was able to start in the VM
• I then went into Codium Settings and disabled all GPU acceleration settings
• Rebooted the VM and now I don't get any GPU warnings/errors in the logs when I run codium --verbose
• Codium is running fine now

If things change I'll post here and track it.

[daiyam]

Have you tried https://github.com/utmapp/UTM?

[d33p-dev]

Have you tried https://github.com/utmapp/UTM?

Hi, yes. Had issues with stability and other bugs so I was trying to find something else. May go back to Parallels. It's the only one so far on Mac that I've found had no bugs and was fast and stable. Thanks. Also tried VMWare Fusion... Not many other options other than just buying some old x64 hardware for Linux machines.

[daiyam]

It's for running x64 Linux? Even on the M4, it's hard.

[d33p-dev]

No, when I use a VM on my M1 MBP, I use Linux ARM. But, to avoid all the hassles of using a VM on Mac for Linux, I think I'll just get a dedicated server for my Linux work. It's too much of a hassle.

I've had all kinds of weird bugs with VBox and UTM... Screen blacking out... Mouse pointer position being about 30-40px offset/incorrect making using a desktop basically impossible.... I don't know... Sucks

[najtin]

This also happens on x86/x64 on Ubuntu 24 with codium from snap on edge (1.101.03933). Codium stable (1.100.33714) works fine.

[1692752:0922/144000.258875:ERROR:gpu_process_host.cc(953)] GPU process exited unexpectedly: exit_code=139
[1692752:0922/144000.258897:WARNING:gpu_process_host.cc(1389)] The GPU process has crashed 9 time(s)

[daiyam]

@d33p-dev Do you also use snap?

[najtin]

Note that exit_code=139 indicates a segmentation fault. Here is the corresponding kernel log:

kernel: codium[1690019]: segfault at 78d9c988a8e0 ip 000078d919afd6bd sp 00007fff7f9b6d38 error 4 in radeonsi_dri.so[d836bd,78d918f10000+10ab000] likely on CPU 12 (core 6, socket 0)

I use the integrated GPU of the AMD Ryzen 7 5800U.

[najtin]

I think this might be related. https://github.com/electron/electron/issues/45862 which was caused by https://issues.chromium.org/issues/396434686 Intel GPUs do not seem to be affected. I'm also on Linux 6.14 so this is plausible.

@d33p-dev Can you please run uname --all in the VM and paste the output here?

Updating electron to 38 might solve this issue.

[najtin]

I did a diff between 1.100.33714 and 1.101.03933

I saw:

--- a/build/linux/riscv64/electron.sha256sums
+++ b/build/linux/riscv64/electron.sha256sums
@@ -1,11 +1,11 @@
-b4df0c94e2c9472e78b58610882b356c2d44621d6b9de208317f14641337ff7f *chromedriver-v34.5.4-linux-riscv64.zip
-aca8846305cb2a89d308b6529feb169d17e2a8a22a7f5cbbb42a884752ef3a83 *electron-v34.5.4-linux-riscv64-debug.tar.zst
-69df7d143196fbac6d111648d827a92172f059e268309de7202c0d2122975396 *electron-v34.5.4-linux-riscv64-symbols.tar.zst
-792dfffa0985b478d79264a48a855ba9bbe00d1406d82b0e74013186cbb6b84b *electron-v34.5.4-linux-riscv64.zip
-898df4e8bc7d96f2e9baf2935f4cc8ecc00acb75aa5efcfac3113ed61bd0415e *ffmpeg-v34.5.4-linux-riscv64.zip
-20c9f293ce544af2c0a30f8cecf5428a8001a0b54a874dee37dddcecc4c7c607 *hunspell-dictionaries.zip
-2005156efe24662203f83a9e99459bb9f85b9215678b90cdc275b1d47ce72b50 *libcxx-headers.zip
-c2b7941916618b9538a72417a2231ec3f4c315e07208e9958f51f7518a786be0 *libcxx-objects-v34.5.4-linux-riscv64.zip
-2078a7264654ddf4675a5bade34dee26ad0971480b17899d610e784411968424 *libcxxabi-headers.zip
-4255e0bf4b63857f8be2beb4e226240a20e38810190e0c6be6afb2e293f2bd27 *mksnapshot-v34.5.4-linux-riscv64.zip
-66e001fec2e77ed97099bcd76d1af40e14b3cbadafea7cb1ef52530610061f96 *node-v34.5.4-headers.tar.gz
+62a100f36cb8898ca4df50b6160c5fc72618f4447486a154b3521e2d5ca58a2a *chromedriver-v35.4.0-linux-riscv64.zip
+92408a3b8a0fdb1be0cdf9473b97a4bb5a0ec3351d3519f5a15831b071eaad27 *electron-v35.4.0-linux-riscv64-debug.tar.zst
+7a7fc08874d7dd9f24a27e06ce4f10223d0b81860408a5a6e67441ca7a7a0df9 *electron-v35.4.0-linux-riscv64-symbols.tar.zst
+b61f163296cc498e459a71839d68f7f1e2d9a5e2cb0ac9e85b1e360f437f4ecc *electron-v35.4.0-linux-riscv64.zip
+41cd1f566a422a59370fc8928a73a4255336f7d870f3eeeabed99b56eb482c6d *ffmpeg-v35.4.0-linux-riscv64.zip
+53b80b77c753d06a01349f7cb1c4eec7d4565366a67fd94abb5748f3204b1bd4 *hunspell-dictionaries.zip
+252d1279aeafe27e1e54f10fbf9cf07ef0ae49d5b1ff8c7c9876ebba616a878b *libcxx-headers.zip
+522a5719369b66749cd966963a94db1c5837d5bc4aecf77caf32f99a8978bfaa *libcxx-objects-v35.4.0-linux-riscv64.zip
+48fb04fb8616d48b9a7125e5b6a038b29b5858f170ae65c4e09b576b7931f7ae *libcxxabi-headers.zip
+f2ab79663741550142623e7af5aa0fc62eff200c43a8c42d5476e06ff70858ca *mksnapshot-v35.4.0-linux-riscv64.zip
+2f4c2d4212fd83f284fef12e1feae01d79bbbd1a68ee05128f1717e0ecfb2b17 *node-v35.4.0-headers.tar.gz

but only for riscv which made me suspicious. According to the hashes in the commit electron should still be 34 on snap edge, if i understand the build system correctly.

However, i checked the snap images and looked at /usr/share/codium/resources/app/package.json inside the snap.

1.100.33714: "electron": "34.5.4", 1.101.03933: "electron": "35.5.1",

[najtin]

electro 34.5.4 should also have been affected. I read the following:

https://github.com/electron/electron/issues/45862#issue-2889650786

Forcing apps to use X11 backend makes them work as expected.

Did codium switch to wayland around that time? There seem to be many wayland related changes between these two versions. git diff 7faa9a9a92c549193f0b1b18fe4fe1260974a19a 9058cdcc7dcbe45e08c4a3232922877729f89539

If 1.101.03933 uses wayland while, 1.100.33714 uses x11, then this would explain why snap stable works even though 34 is already affected.

[d33p-dev]

@najtin here's the uname --all:

Linux devuser 6.8.0-79-generic #79-Ubuntu SMP PREEMPT_DYNAMIC Tue Aug 12 14:33:58 UTC 2025 aarch64 aarch64 aarch64 GNU/Linux

[najtin]

Thanks, that checks out. In the chromium issue above there is a link to this issue https://github.com/NixOS/nixpkgs/issues/382612#issuecomment-2810403341 which makes it seems like all recent kernels are affected.

@d33p-dev Can you please answer the following questions:

• how did you install codium? did you install via snap or something else?
• what version of codium are you running? please provide the output of codium --verison
• also please provide the output of echo $XDG_SESSION_TYPE so that we can confirm you are running wayland.

Yours and mine might be different issues. Maybe i should open a new issue @daiyam ?

[d33p-dev]

Version - 1.104.16282 b18126fb99b60533fc069575d08d72758cd90fed arm64

Install -
Honestly, I forget... I'll try to remember. I think I just hit the site and followed the instructions and added your repo to the package lists (if that's the right terminology)...

XDG_SESSION_TYPE - x11

I'm running KDE if that helps as well.

I haven't had any issues after I went through the steps mentioned above about disabling VBox extensions, rebooting host and then disabling all GPU related features in Codium. This VM has no GPU in it... I tried to set it up some it had GPU Enabled but it would crash the VM.... I've had problems with every virtual machine manager except Parallels on this M1 Mac. But, at this point, I've got a stable, non GPU, virtual box VM running well and codium working great now...

I think the whole issue was unstable VBox issues when I enabled extensions for VBox...

[daiyam]

Can you try the Insiders version at https://github.com/VSCodium/vscodium-insiders/releases/tag/1.105.06769-insider? Thx

[daiyam]

Can you try the version 1.105 from the edge channel?

[najtin]

Can you try the version 1.105 from the edge channel?

the snap 1.105 seems to work for me. :) thanks!

[najtin]

Since the issue of @d33p-dev seems to be resolved and mine is too, I suggest closing this issue. Thanks for fixing this issue.

[daiyam]

I've pushed it as stable