The symtom of this problem is that everything takes forever to start: Terminal, emacs, Thunar, etc. Investigating I find the following in my logs: Sep 15 21:43:25 [kernel] traps: gvfsd[2157] trap int3 ip:38b480f01f5 sp:3c99d55cd20 error:0 Apparently the daemon crashes afterwards, because grsec prevents it from dumping core: Sep 15 21:43:25 [kernel] grsec: denied resource overstep by requesting 4096 for RLIMIT_CORE against limit 0 for /usr/libexec/gvfsd[gvfsd:2157] uid/euid:1000/1000 gid/egid:1000/1000, parent /sbin/init[init:1] uid/euid:0/0 gid/egid:0/0 I found the forum thread in $URL, and tried downgrading to gvfs-1.22.4. After downgrading and killing anything with "gvfs" in the name, things quickly went back to normal: applications launch quickly, my little trash icon came back... normal.
Please recompile gvfs-1.24.2 and relevant dependencies with debugging symbols and attach a gdb backtrace. Diagnosing a crash in a large user-space program from a few dmesg lines is unfortunately impossible. Also, please look in your journald entries for anything else related to gvfsd. Also, assuming you have a non-grsec system around, please check if this issue happens on non-hardened.
app-admin/abrt may be useful for obtaining a backtrace from a crashing daemon if you can't make gvfsd crash from the terminal.
Also, "emerge --info gvfs" please.
Created attachment 412016 [details] emerge --info I'm in the middle of something important and can't rebreak things at the moment, but emerge --info is easy. And here's... $ emerge -pv1 =gnome-base/gvfs-1.24.2 [ebuild U #] gnome-base/gvfs-1.24.2::gentoo [1.22.4::gentoo] USE="fuse gtk http udev -afp -archive -bluray -cdda -gnome-online-accounts -gphoto2 -ios -libsecret -mtp -nfs% -samba -systemd {-test} -udisks -zeroconf" 0 KiB There's nothing else in the logs. I can build a grsec-free kernel, but I don't think /that/ will help: the grsec warning is just letting me know that something (gvfsd) tried to dump core. If anything hardened is responsible, it would be the full stack smashing protection -- we compile with -fstack-protector-all.
As a side note, for knowing a bit more about how to take advantage of abrt to catch this crashes, please take a look to https://wiki.gentoo.org/wiki/Project:GNOME/GNOME3-Troubleshooting#Getting_backtraces (and feel free to improve it if you thing something is missing :))
Created attachment 414504 [details] core_backtrace from abrt
Created attachment 414506 [details] backtrace from abrt Sorry, I forgot all about this. I rebuilt gvfs, glib, and libffi with vanilla gcc-4.9.3 and all of the debug voodoo. I caught the crash with abrt and generated a backtrace. Does this have what you need?
nice, thanks Can you please report the crash to upstream: https://bugzilla.gnome.org/enter_bug.cgi?product=gvfs Please paste the backtrace as a comment as their bugzilla is able to find similar traces in that way Once that is done, please let us know the link to the bug report for letting us to track the issue Thanks a lot
Here's the upstream bug: https://bugzilla.gnome.org/show_bug.cgi?id=756885
Created attachment 415054 [details, diff] fix-crash-on-no-monitor-impls.patch I haven't rebooted yet, but I killed off my running gvfs processes and the newly-spawned ones seem to work with the patch.
[master 788c905] gnome-base/gvfs: Apply upstream fixes, also including a fix for crash reported in bug #560592 (by Michael Orlitzky); drop old. 8 files changed, 260 insertions(+), 124 deletions(-) create mode 100644 gnome-base/gvfs/files/gvfs-1.24.2-crash-monitor.patch create mode 100644 gnome-base/gvfs/files/gvfs-1.24.2-g_warning.patch create mode 100644 gnome-base/gvfs/files/gvfs-1.24.2-guard-caches.patch create mode 100644 gnome-base/gvfs/files/gvfs-1.24.2-remote-proxy.patch create mode 100644 gnome-base/gvfs/files/gvfs-1.24.2-untrashable.patch delete mode 100644 gnome-base/gvfs/gvfs-1.22.3.ebuild rename gnome-base/gvfs/{gvfs-1.24.1.ebuild => gvfs-1.24.2-r1.ebuild} (81%)
