Either of glib or glib-networking or gvfs (maybe even something else) "breaks" applications (only GTK+ ones so far) resulting in very long loading times until a timeout is reached (thunar takes 30s per window/folder on an SSD). For every application started, an entry like this can be found in `dmesg` > traps: gvfsd[3101] trap int3 ip:7f6c94debc60 sp:7ffd9bd45c20 error:0 Googling for the error shows a Debian bug (https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=696219) from 2012 saying it's because of gsettings-daemon not running. That should have been/was fixed but seems to have been re-introduced. Masking, downgrading and rebuilding the mentioned libs and the applications brings back the normal behavior. As this is a system with FVWM, I see no need for and don't want to run gsettings-daemon, if this is the problem. Reproducible: Always
1. *Which* applications? Please give a few of the simplest applications (not complex things like chromium or firefox) where the symptoms can be observed. And please explain exactly when in these applications the slowdown happens (e.g. after starting application, window is grey for 30 seconds, then the contents appear; "save" dialog takes 30 seconds to show; that sort of explanation). We need a specific test case from you before we can begin to address the bug! 2. Please attach "emerge --info dconf glib glib-networking gvfs gtk+" output. 3. If you are using systemd, please attach journalctl output beginning at just before a problematic application is launched. 4. If you are not using systemd - launch a few of the problematic application from the terminal, attach the that errors they print (if any). 5. If you are not using systemd, please attach your desktop session's error log. (I have no idea where fvwm stores it, up to you to figure that out. Old pre-systemd gnome versions used ~/.xsession-errors)
(In reply to Alexandre Rostovtsev from comment #1) > 1. *Which* applications? Please give a few of the simplest applications (not > complex things like chromium or firefox) where the symptoms can be observed. > And please explain exactly when in these applications the slowdown happens > (e.g. after starting application, window is grey for 30 seconds, then the > contents appear; "save" dialog takes 30 seconds to show; that sort of > explanation). Startup(meaning taking 30s to show, usually almost instant thanks to SSD): firefox, chromium, gimp, thunar, keepass (not keepassx), komodo-ide/-edit (based to on firefox/gecko iirc) After that, another slow down happens (again for pretty much the same time) when the first file access is done. So f.e. opening a file-save dialog or when Firefox first tries to cache something on disk. After that initial slowdown, successive actions of the same kind work as normal. OpenOffice starts normal, but trying to open a file results in the same delay to spawn the file-open dialog. The given applications are pretty much all GUI applications installed, shell tools work normal. > > We need a specific test case from you before we can begin to address the bug! > > 2. Please attach "emerge --info dconf glib glib-networking gvfs gtk+" output. Will do. > 3. If you are using systemd, please attach journalctl output beginning at > just before a problematic application is launched. Normal default installation running openrc/sysv > 4. If you are not using systemd - launch a few of the problematic > application from the terminal, attach the that errors they print (if any). thunar, gimp: org.gtk.vfs.MountTracker.listMountableInfo call failed: Timeout was reached (g-io-error-quark, 24) (others tested so far print either no message at all or normal/unrelated stuff) > 5. If you are not using systemd, please attach your desktop session's error > log. (I have no idea where fvwm stores it, up to you to figure that out. Old > pre-systemd gnome versions used ~/.xsession-errors) I have FVWM setup to log to .xsession-errors, however, it has nothing unexpected in it, just my normal debug messages I use. Don't know if it's important, but the offending behavior only happened after a scheduled reboot after these updates have been installed - a X.org restart might have been enough, don't know. So if you/someone wants to test it, please also reboot/restart X before.
Created attachment 406138 [details] einfo
(In reply to avx from comment #2) > thunar, gimp: > org.gtk.vfs.MountTracker.listMountableInfo call failed: Timeout was reached > (g-io-error-quark, 24) Thanks. This would imply /usr/libexec/gvfsd is failing to start. Please check - do you have any gvfsd processes running? (ps aux | grep gvfsd) If none are running, what happens if you start /usr/libexec/gvfsd manually? (If it crashes - rebuild glib and gvfs with -ggdb in CFLAGS and splitdebug in FEATURES and get a backtrace from gdb, see https://wiki.gentoo.org/wiki/Project:Quality_Assurance/Backtraces for instructions.)
> Please check - do you have any gvfsd processes running? (ps aux | grep gvfsd) --snip-- ps aux | grep gvfsd avx 8698 0.0 0.0 347468 8792 ? Sl 21:50 0:00 /usr/libexec/gvfsd-fuse /home/avx/.gvfs -f -o big_writes avx 8708 0.0 0.0 183304 5544 ? Sl 21:50 0:00 /usr/libexec/gvfsd avx 9011 0.0 0.0 12040 2520 pts/1 S+ 22:47 0:00 grep --color=auto gvfsd --snap-- (this is the current status after some of the mentioned applications have been started for at least one time - if you also need output of a fresh session before starting any of those applications, let me know) > If none are running, what happens if you start /usr/libexec/gvfsd manually? > (If it crashes - rebuild glib and gvfs with -ggdb in CFLAGS and splitdebug > in FEATURES and get a backtrace from gdb, see > https://wiki.gentoo.org/wiki/Project:Quality_Assurance/Backtraces for > instructions.) As it seems it's currently running, the following output after trying to start it again is probably moot, but to make sure: "Failed to acquire daemon name, perhaps the VFS daemon is already running?" (it obviously is) Sidenote, I'll be gone for roughly 36 hours starting in an hour, so might take a while to reply to possible further comments. Thanks so far.
"Confirming" for myself, just updated another machine and the same problem occurs.
I cannot reproduce this at all :/, and I can't see anything about this with 2.44.x in other distributions. Long time ago not building dbus-glib after glib update caused some problems, maybe you could try to rebuild dbus-glib after glib bump then
(In reply to Pacho Ramos from comment #7) > I cannot reproduce this at all :/, and I can't see anything about this with > 2.44.x in other distributions. Long time ago not building dbus-glib after > glib update caused some problems, maybe you could try to rebuild dbus-glib > after glib bump then Thanks for the hint Pacho, tried recompiling it and the affected applications, also restarted dbus, no change. However, the culprit seems more to be on the gvfs side, I removed gvfs and built thunar with USE="-dbus" (as the flag pulls in gvfs), after that it works as usual again. Same for other applications, speedy startup as I'm used to, no problems any longer with file dialogs. But of course that comes with the tradeoff of broken functionality, f.e. thumbnailing in thunar no longer works.
I encountered this problem as well today. Almost every application was taking 30+ seconds to start (Firefox, KeePass, gucharmap, but not gVim or lilyterm). Furthermore, running `gvfs-mount -l` also had a long delay, both before and after printing this error message: > org.gtk.vfs.MountTracker.listMountableInfo call failed: Timeout was reached (g-io-error-quark, 24) Downgrading to =gnome-base/gvfs-1.22.4 resolved the issue immediately. dmesg has several errors like this: [ 197.108521] traps: gvfsd[2833] trap int3 ip:7f0a9b7029e7 sp:7ffcb6d61dd0 error:0
I wonder if maybe reporting this to gvfs upstream (bugzilla.gnome.org) could help as maybe they will know how to get more information :/ Could you try? Thanks
Sorry, had been off for a while...theoretically that could help, yes, but personally I'm currently not really willing to do that as my experiences with GNOME people have been pretty much all on the bad side and a waste of time.
It will then be really hard to find the problem as none of us are able to reproduce it downstream :( The reason for we wanting you to be the reporter is that you will be the one able to provide any information upstream could need but, anyway, we would be CCed there to let us track the issue (and also reply any doubts we are able to) :/
Please also try with 2.46 glib
