So I checked another arch based distro ran it for a while and got no core dumps but its happening here in EOS.
The core dumps aren’t just caused due to picom. Other processes are returning core dumps too but I couldn’t post them here as I reinistalled just today and picom was the only one that gave core dump till now.
Output of coredumpctl :
Yeah, tested it with picom. It’s not just picom, other processes are doing it as well like xdg-desktop-portal, some bluetooth stuff, gcr prompter.
That’s the reason I reinstalled.
Signal 11 means segfault. And it’s a different service this time. Last time it was picom. Are the services affected consistent, or do they seem random? If they are consistent (e.g. it’s always the same set of services that are affected), then it might be worth looking into what all those processes have in common (e.g: do they use the same library, etc.). If they seem random, then there might be a deeper issue at play (hardware? kernel? graphics driver?).
What else have you tried other than tested it on Arch? Have you tested it on the LTS kernel? Have you tested the machine on a non-Arch-based distro?
P/S: Maybe also post the output of journalctl --since "2023-08-14 01:00" just to see what else is inside the journals around the time the segfault occurred.
yeah kernel’s not a problem, i have checked on lts kernel as well.
Here’s the output of :
journalctl --since “2023-08-14 00:56”
I used different time stamps, earlier than what u said as timestamps after the core dump are not useful
56:53 archlinux rtkit-daemon[881]: Failed to look up client: No such file or directory
Aug 14 00:56:53 archlinux rtkit-daemon[881]: Failed to look up client: No such file or directory
Aug 14 00:56:54 archlinux rtkit-daemon[881]: Failed to look up client: No such file or directory
Aug 14 00:56:54 archlinux rtkit-daemon[881]: Failed to look up client: No such file or directory
Aug 14 00:56:55 archlinux rtkit-daemon[881]: Failed to look up client: No such file or directory
Aug 14 00:56:55 archlinux xdg-desktop-por[1027]: g_object_ref: assertion '!object_already_finalized' failed
Aug 14 00:56:55 archlinux kernel: pool-/usr/lib/x[55030]: segfault at 40 ip 00007fa9c475fc2b sp 00007fa9aaffccf8 error 6 in libglib-2.0.so.0.7600.4[7fa9c46ce000+9d000] likely on CPU 3 (core 3, socket 0)
Aug 14 00:56:55 archlinux kernel: Code: 0b 75 c4 44 89 2b eb bf 0f 1f 80 00 00 00 00 48 83 c4 08 5b 5d 41 5c 41 5d c3 0f 1f 44 00 00 f3 0f 1e fa 31 c0 ba 01 00 00 00 <f0> 0f b1 17 75 01 c3 e9 79 ff ff ff 66 0f 1f 84 00 00 00 00 00 f3
Aug 14 00:56:55 archlinux systemd[1]: Created slice Slice /system/systemd-coredump.
Aug 14 00:56:55 archlinux systemd[1]: Started Process Core Dump (PID 55083/UID 0).
Aug 14 00:56:55 archlinux systemd-coredump[55089]: [🡕] Process 1027 (xdg-desktop-por) of user 1000 dumped core.
Stack trace of thread 55030:
#0 0x00007fa9c475fc2b g_mutex_lock (libglib-2.0.so.0 + 0xafc2b)
#1 0x000055ab771a1d81 n/a (xdg-desktop-portal + 0x66d81)
#2 0x00007fa9c4586838 n/a (libgio-2.0.so.0 + 0xac838)
#3 0x00007fa9c473fd53 n/a (libglib-2.0.so.0 + 0x8fd53)
#4 0x00007fa9c473cd75 n/a (libglib-2.0.so.0 + 0x8cd75)
#5 0x00007fa9c408c9eb n/a (libc.so.6 + 0x8c9eb)
#6 0x00007fa9c411123c n/a (libc.so.6 + 0x11123c)
Stack trace of thread 1027:
#0 0x00007fa9c4060150 n/a (libc.so.6 + 0x60150)
#1 0x00007fa9c4081125 n/a (libc.so.6 + 0x81125)
#2 0x00007fa9c4761593 g_vasprintf (libglib-2.0.so.0 + 0xb1593)
#3 0x00007fa9c472d802 g_strdup_vprintf (libglib-2.0.so.0 + 0x7d802)
#4 0x00007fa9c472d8ce g_strdup_printf (libglib-2.0.so.0 + 0x7d8ce)
#5 0x00007fa9c4585d72 n/a (libgio-2.0.so.0 + 0xabd72)
#6 0x00007fa9c449a8b4 g_object_unref (libgobject-2.0.so.0 + 0x228b4)
#7 0x00007fa9c47046fd n/a (libglib-2.0.so.0 + 0x546fd)
#8 0x00007fa9c4708f20 n/a (libglib-2.0.so.0 + 0x58f20)
#9 0x00007fa9c470ab39 g_main_context_dispatch (libglib-2.0.so.0 + 0x5ab39)
#10 0x00007fa9c4767cc9 n/a (libglib-2.0.so.0 + 0xb7cc9)
#11 0x00007fa9c4709fef g_main_loop_run (libglib-2.0.so.0 + 0x59fef)
#12 0x000055ab7715f601 n/a (xdg-desktop-portal + 0x24601)
#13 0x00007fa9c4027cd0 n/a (libc.so.6 + 0x27cd0)
#14 0x00007fa9c4027d8a __libc_start_main (libc.so.6 + 0x27d8a)
#15 0x000055ab7715fa85 n/a (xdg-desktop-portal + 0x24a85)
Stack trace of thread 1036:
#0 0x00007fa9c41039df __poll (libc.so.6 + 0x1039df)
#1 0x00007fa9c4767c2f n/a (libglib-2.0.so.0 + 0xb7c2f)
#2 0x00007fa9c47080e2 g_main_context_iteration (libglib-2.0.so.0 + 0x580e2)
#3 0x00007fa9c4708132 n/a (libglib-2.0.so.0 + 0x58132)
#4 0x00007fa9c473cd75 n/a (libglib-2.0.so.0 + 0x8cd75)
#5 0x00007fa9c408c9eb n/a (libc.so.6 + 0x8c9eb)
#6 0x00007fa9c411123c n/a (libc.so.6 + 0x11123c)
Stack trace of thread 1091:
#0 0x00007fa9c41039df __poll (libc.so.6 + 0x1039df)
#1 0x00007fa9c4767c2f n/a (libglib-2.0.so.0 + 0xb7c2f)
#2 0x00007fa9c47080e2 g_main_context_iteration (libglib-2.0.so.0 + 0x580e2)
#3 0x00007fa9c0ea5fde n/a (libdconfsettings.so + 0x5fde)
#4 0x00007fa9c473cd75 n/a (libglib-2.0.so.0 + 0x8cd75)
#5 0x00007fa9c408c9eb n/a (libc.so.6 + 0x8c9eb)
#6 0x00007fa9c411123c n/a (libc.so.6 + 0x11123c)
Stack trace of thread 1092:
#0 0x00007fa9c4111666 epoll_wait (libc.so.6 + 0x111666)
#1 0x00007fa9c0e69c59 n/a (libspa-support.so + 0x15c59)
#2 0x00007fa9c0e5c4fd n/a (libspa-support.so + 0x84fd)
#3 0x00007fa9c43b0b12 n/a (libpipewire-0.3.so.0 + 0x45b12)
#4 0x00007fa9c408c9eb n/a (libc.so.6 + 0x8c9eb)
#5 0x00007fa9c411123c n/a (libc.so.6 + 0x11123c)
Stack trace of thread 1039:
#0 0x00007fa9c410f1ad syscall (libc.so.6 + 0x10f1ad)
#1 0x00007fa9c475fca7 g_cond_wait (libglib-2.0.so.0 + 0xafca7)
#2 0x00007fa9c46d5144 n/a (libglib-2.0.so.0 + 0x25144)
#3 0x00007fa9c473f2fe n/a (libglib-2.0.so.0 + 0x8f2fe)
#4 0x00007fa9c473cd75 n/a (libglib-2.0.so.0 + 0x8cd75)
#5 0x00007fa9c408c9eb n/a (libc.so.6 + 0x8c9eb)
#6 0x00007fa9c411123c n/a (libc.so.6 + 0x11123c)
Stack trace of thread 1042:
#0 0x00007fa9c41039df __poll (libc.so.6 + 0x1039df)
#1 0x00007fa9c4767c2f n/a (libglib-2.0.so.0 + 0xb7c2f)
#2 0x00007fa9c4709fef g_main_loop_run (libglib-2.0.so.0 + 0x59fef)
#3 0x00007fa9c45ea28c n/a (libgio-2.0.so.0 + 0x11028c)
#4 0x00007fa9c473cd75 n/a (libglib-2.0.so.0 + 0x8cd75)
#5 0x00007fa9c408c9eb n/a (libc.so.6 + 0x8c9eb)
#6 0x00007fa9c411123c n/a (libc.so.6 + 0x11123c)
Stack trace of thread 55082:
#0 0x00007fa9c410f1ad syscall (libc.so.6 + 0x10f1ad)
#1 0x00007fa9c4760533 g_cond_wait_until (libglib-2.0.so.0 + 0xb0533)
#2 0x00007fa9c46d5115 n/a (libglib-2.0.so.0 + 0x25115)
#3 0x00007fa9c473fdab n/a (libglib-2.0.so.0 + 0x8fdab)
#4 0x00007fa9c473cd75 n/a (libglib-2.0.so.0 + 0x8cd75)
#5 0x00007fa9c408c9eb n/a (libc.so.6 + 0x8c9eb)
#6 0x00007fa9c411123c n/a (libc.so.6 + 0x11123c)
ELF object binary architecture: AMD x86-64
Aug 14 00:56:55 archlinux systemd[785]: xdg-desktop-portal.service: Main process exited, code=dumped, status=11/SEGV
Aug 14 00:56:55 archlinux systemd[1]: systemd-coredump@0-55083-0.service: Deactivated successfully.
Aug 14 00:56:55 archlinux dbus-daemon[802]: [session uid=1000 pid=802] Activating via systemd: service name='org.freedesktop.portal.Desktop' unit='xdg-desktop-portal.service' requested by ':1.4437' (uid=1000 pid=55084 comm="amixer -D default get Master")
Aug 14 00:56:55 archlinux systemd[785]: xdg-desktop-portal.service: Failed with result 'core-dump'.
Aug 14 00:56:55 archlinux systemd[785]: xdg-desktop-portal.service: Consumed 20.702s CPU time.
Aug 14 00:56:55 archlinux systemd[785]: Starting Portal service...
Aug 14 00:56:55 archlinux rtkit-daemon[881]: Supervising 11 threads of 8 processes of 1 users.
Aug 14 00:56:55 archlinux rtkit-daemon[881]: Supervising 11 threads of 8 processes of 1 users.
Aug 14 00:56:55 archlinux rtkit-daemon[881]: Supervising 11 threads of 8 processes of 1 users.
Aug 14 00:56:55 archlinux dbus-daemon[802]: [session uid=1000 pid=802] Successfully activated service 'org.freedesktop.portal.Desktop'
Aug 14 00:56:55 archlinux systemd[785]: Started Portal service.
Aug 14 00:56:56 archlinux rtkit-daemon[881]: Failed to look up client: No such file or directory
On eos i got these dumps from 3-4 different processes not just picom and xdg-desktop-portal
But here so far it’s only xdg-desktop-portal which is dumping core. Maybe if I let it drive for some days from now, new entries might be added.
But I tried to replicate the same packages on both systems so I could test. Except the packages from eos repo, all other packages are the same on arch which i had on eos.
There is now way to answer that question. However, in cases where there is a lack of viable information, we can try things one at a time and try to isolate the problem.
If it is doesn’t help, we know that isn’t the cause. If it does help, we know the issue is with picom and we can dig deeper into why.