AppImage Crashes on Startup Due to GPU Process Error on Linux

[plinkr]

OS

Linux

VERSION

This is an up to date Manjaro Linux distro:

System:
  Kernel: 5.15.165-1-MANJARO arch: x86_64 bits: 64
  Desktop: Cinnamon v: 6.2.9 Distro: Manjaro Linux
CPU:
  Info: quad core Intel Core i7-6700HQ [MT MCP] @ 2.60GHz
Graphics:
  Device-1: Intel HD Graphics 530 driver: i915 v: kernel
  Device-2: NVIDIA GM107M [GeForce GTX 960M] driver: nvidia v: 550.107.02
  Display: x11 server: X.org v: 1.21.1.13 with: Xwayland v: 24.1.2 driver:
    X: loaded: modesetting,nvidia gpu: i915 resolution: 1920x1080~60Hz
  API: OpenGL v: 4.6.0 compat-v: 4.5 vendor: nvidia mesa v: 550.107.02
    renderer: NVIDIA GeForce GTX 960M/PCIe/SSE2
Info:
  Memory: total: 32 GiB note: est. available: 31.16 GiB used: 5.16 GiB (16.5%)

ISSUE DESCRIPTION

The application fails to launch on my Linux system. The app opens briefly but then crashes immediately. The terminal outputs several errors, including GPU process failures, and the application ultimately results in a core dump:

./Another-Redis-Desktop-Manager.1.6.7.AppImage 
libva error: vaGetDriverNames() failed with unknown libva error
libva error: vaGetDriverNames() failed with unknown libva error
libva error: vaGetDriverNames() failed with unknown libva error
[6579:0904/131140.945110:FATAL:gpu_data_manager_impl_private.cc(415)] GPU process isn't usable. Goodbye.
Trace/breakpoint trap (core dumped)

Temporary Workaround: I was able to get the application to open successfully by using the --no-sandbox flag as follows:

./Another-Redis-Desktop-Manager.1.6.7.AppImage --no-sandbox

[qishibo]

yes you can use --no-sandbox ro run this app ref https://github.com/qishibo/AnotherRedisDesktopManager/issues/1014#issuecomment-1402983419 and I'll try to find a correct version of electron to fix GPU issues

[quevon24]

I'm getting the same error, these are my specs:

OS: Linux Mint 22 x86_64
Kernel: 6.8.0-38-generic
DE: Cinnamon 6.2.9 
CPU: AMD Ryzen 7 5800X (16) @ 3.200G 
GPU: NVIDIA GeForce RTX 3070 Lite Hash
Memory: 31995MiB 

The temporary workaround works fine