You are not logged in.
Hi everyone,
I have been having this very weird behaviour that i have no idea what to do about. I am working on porting a vulkan/SDL3 application on linux.
I have progressed quite well but at some point it might crash taking down all of my gnome WM and getting me back to the login screen!
I am not asking for help fixing the application (something is wrong in vulkan/scene objects), what i am trying to understand/fix is how is it possible that a user applicatiion crashes the window manager.
Any ideas/pointers are welcome, thank you
Offline
Wayland applications that crash are known to often take the whole environment down with them , and gnome appears to be very susceptible to this .
Are you running gnome on wayland or X ?
Disliking systemd intensely, but not satisfied with alternatives so focusing on taming systemd.
clean chroot building not flexible enough ?
Try clean chroot manager by graysky
Offline
This could also be a way more trivial bug in gnome:
Client does something with the window, windowmanager cannot deal gracefully with that, WM crashes (bug in the WM)
Since in gnome as much functionality as possible is stuffed into one process and 3rd party extensions are provided by monkey-patching some javascript (executed in that process), some bug in some taskbar extension might crash the session and the display server…
Also gtk recently added a fatal assertion that has caused multiple "core gnome applications" to crash, https://gitlab.gnome.org/GNOME/gtk/-/me … uests/7836
=> Check the system journal and also https://wiki.archlinux.org/title/Core_d … _core_dump for what actually crashes.
Notably your client "crashing" in response to losing contact to the display server (common client/toolkit strategy on X11 and wayland, though unnecessary on either server) is an option, too.
Offline
Hi guys, thank you very much for your answers! (sorry for the late reply)
Yes, i am running gnome on wayland.
Also thanks a lot for the reference to coredumpctl, i did not know that. However I already know that my app crashes, it doesn't offer me any new info.
I know my app is broken, i need to fix sth in vulkan initialization. I am surprised that issues in a single app can take down the WM! I mean, come guys, i have been making fun of w95 for the last 30 years and now here we are?
Last edited by nspattak (2025-03-23 15:26:08)
Offline
The coredumpctl check wasn't about your app, you want to see why gnome is crashing.
I mean, come guys, i have been making fun of w95 for the last 30 years and now here we are?
Since in gnome as much functionality as possible is stuffed into one process and 3rd party extensions are provided by monkey-patching some javascript (executed in that process), some bug in some taskbar extension might crash the session and the display server…
Not so much "a WM", but in general clients can of course trigger bugs in WMs.
Offline
The coredumpctl check wasn't about your app, you want to see why gnome is crashing.
Please correct me if i am missing sth obvious but it seems pretty clear to me that a sync list semaphore is causing a crash in my app:
PID: 225163 (spartan_vulkan)
UID: 1000 (pattakosn)
GID: 1000 (pattakosn)
Signal: 6 (ABRT)
Timestamp: Sun 2025-03-16 10:31:43 CET (1 week 0 days ago)
Command Line: ./spartan_vulkan
Executable: /home/pattakosn/github.com/SpartanMineMaster/build/bin/spartan_vulkan
Control Group: /user.slice/user-1000.slice/user@1000.service/app.slice/app-org.gnome.Terminal.slice/vte-spawn-b8ef06ed-617a-48ce-9f34-2c6aa878304e.scope
Unit: user@1000.service
User Unit: vte-spawn-b8ef06ed-617a-48ce-9f34-2c6aa878304e.scope
Slice: user-1000.slice
Owner UID: 1000 (pattakosn)
Boot ID: 143cd2cddafd4df280ce96586a5ab3c9
Machine ID: 7523429978fe4c77a999b73499334e28
Hostname: jimarch
Storage: /var/lib/systemd/coredump/core.spartan_vulkan.1000.143cd2cddafd4df280ce96586a5ab3c9.225163.1742117503000000.zst (present)
Size on Disk: 180.5M
Message: Process 225163 (spartan_vulkan) of user 1000 dumped core.
Module libOpenImageDenoise_device_hip.so.2.3.2 without build-id.
Module libdxil.so without build-id.
Module libdxcompiler.so without build-id.
Stack trace of thread 225163:
#0 0x00007e12f80a5624 n/a (libc.so.6 + 0x97624)
#1 0x00007e12f804bba0 raise (libc.so.6 + 0x3dba0)
#2 0x00007e12f8033582 abort (libc.so.6 + 0x25582)
#3 0x00007e12f80334eb n/a (libc.so.6 + 0x254eb)
#4 0x00007e12f912ac97 _ZN7spartan9semaphore4waitEmmRPv (libruntime.so + 0x72ac97)
#5 0x00007e12f912bd1c _ZN7spartan17RHI_SyncPrimitive4WaitEm (libruntime.so + 0x72bd1c)
#6 0x00007e12f905ee1b _ZN7spartan15RHI_CommandList16WaitForExecutionEv (libruntime.so + 0x65ee1b)
#7 0x00007e12f910424d _ZN7spartan9RHI_Queue15NextCommandListEv (libruntime.so + 0x70424d)
#8 0x00007e12f90d2e0a _ZN7spartan10RHI_Device4TickEm (libruntime.so + 0x6d2e0a)
#9 0x00007e12f8f8e012 _ZN7spartan8Renderer4TickEv (libruntime.so + 0x58e012)
#10 0x00007e12f8e7242a _ZN7spartan6Engine4TickEv (libruntime.so + 0x47242a)
#11 0x000062e30a848ea2 n/a (n/a + 0x0)
#12 0x000062e30a9f1e33 n/a (n/a + 0x0)
#13 0x00007e12f8035488 n/a (libc.so.6 + 0x27488)
#14 0x00007e12f803554c __libc_start_main (libc.so.6 + 0x2754c)
#15 0x000062e30a843975 n/a (n/a + 0x0)
ELF object binary architecture: AMD x86-64
edit: full coredumpctl trace
Last edited by nspattak (2025-03-23 20:30:11)
Offline
Nobody doubts that your process is crashing, but if gnome crashes along, it's the gnome-crash backtraces you want to look at to understand *why*.
Gnome crashing being the cause of your process crashing was just an extreme example of what the situation also might look like, but you'll *have* to look at the actual gnome crash to understand it.
Offline