Red Hat Bugzilla – Bug 458944
Coredumping in ask_password_reply
Last modified: 2015-03-03 17:33:03 EST
Description of problem:
Recently my coredump directory started to contain lots of gvfs cores.
#0 0x00007f883914b16c in ask_password_reply (op=0x6363f0, result=<value optimized out>,
data=<value optimized out>) at gmountoperationdbus.c:183
#1 0x0000000000000001 in ?? ()
#2 0x000000000061fac0 in ?? ()
#3 0x00007f883eff805d in g_main_context_iterate (context=0x3, block=1, dispatch=1,
self=<value optimized out>) at gmain.c:2705
#4 0x00007f883eff858d in IA__g_main_loop_run (loop=0x630400) at gmain.c:2928
#5 0x000000000040ab70 in daemon_main (argc=4, argv=<value optimized out>, max_job_threads=10,
default_type=0x41948e "trash", mountable_name=0x0, first_type_name=<value optimized out>)
#6 0x000000000040adce in main (argc=4, argv=0x7fff485e9948) at daemon-main-generic.c:39
#0 0x00007f2d99fa7e43 in g_mount_spec_from_dbus (iter=0x63fda0) at gmountspec.c:263
#1 0x0000000000000000 in ?? ()
Version-Release number of selected component (if applicable):
Steps to Reproduce:
Any hints on how to trigger this ?
Unfortunately I usually discover this coredump file after some time in my coredump directory - I do not even know what is process /usr/libexec/gvfsd-trash good for :) - how do I know it's not working so I could better notice what I've been doing during the crash ?
Hmm I could probably write a script to detect coredump and notify myself, when this happens...
We've recently fixed some tricky crashes in the trash daemon, so this may be fixed. Let me know if you are still seeing this in current rawhide.
I'm going to go ahead and close this bug out. If another core file shows up, please reopen.