I've also noticed this error when running gnome-system-monitor from the terminal:
glibtop(c=2365): [WARNING] statvfs '/run/user/1000/doc' failed: Operation not permitted It looks like it's trying to read that path and failing and when I check that directory it says the date of it and all its containing files are from Jan 1 1970. Aka the epoch. So I have a feeling that this glibtop is choking on something flatpaks are doing maybe? Unsure, hope the extra info helps. On Sat, 30 Nov 2024 at 02:38, Konomi <konomikit...@gmail.com> wrote: > > It seems to only crash when I have the flatpak of Tuba open > (https://flathub.org/apps/dev.geopjr.Tuba) but it only crashes at > startup if I have gnome-system-monitor already open then launch tuba > it doesn't crash. If I have tuba open and try to launch > gnome-system-moitor the system monitor crashes. > > Konomi > > On Sat, 30 Nov 2024 at 02:30, Konomi <konomikit...@gmail.com> wrote: > > > > No, there's no long disk names. I did however notice that when I open > > certain applications that are flatpaks the issue occurs. I'm trying to > > figure out which one is causing the problem. > > > > Konomi > > > > On Sat, 30 Nov 2024 at 02:17, Simon McVittie <s...@debian.org> wrote: > > > > > > Control: retitle -1 gnome-system-monitor: strcpy overflow inside > > > glibtop_get_disk_l() > > > Control: reassign -1 libgtop-2.0-11 2.41.3-1 > > > Control: affects -1 + gnome-system-monitor > > > > > > On Sat, 30 Nov 2024 at 00:43:47 +1100, Konomi wrote: > > > > gnome-system-monitor instantly crashes on my system. coredumpctl shows > > > > the > > > > following information: > > > ... > > > > #5 0x00007f1d50525d00 __GI___chk_fail (libc.so.6 + > > > > 0x11bd00) > > > > #6 0x00007f1d50527622 __GI___strcpy_chk (libc.so.6 + > > > > 0x11d622) > > > > #7 0x00007f1d52a93304 n/a (libgtop-2.0.so.11 + 0xa304) > > > > #8 0x00007f1d52a8f92b glibtop_get_disk_l > > > > (libgtop-2.0.so.11 + > > > > 0x692b) > > > > #9 0x000055ca3c4ede9b n/a > > > > (/usr/bin/gnome-system-monitor + > > > > 0x39e9b) > > > > > > You were correct to report this to gnome-system-monitor at first, but > > > this looks like a string buffer overflow inside libgtop being caught by > > > glibc's "fortify" hardening, so I'm reassigning this to the version of > > > libgtop you seem to have been using. > > > > > > Looking at sysdeps/linux/disk.c, there are some unsafe-looking uses of > > > strcpy() which could well be the problem here. > > > > > > If you run 'lsblk --output NAME,TYPE -i -n' in a terminal, do any of the > > > drives that are listed have unusually long values for the name or type? > > > > > > smcv
