FreeBSD Port: fusefs-libs-2.7.2_1 - gvfs-fuse-daemon process(es) stuck

[Matt]

On Tue, May 6, 2008 at 12:32 AM, Jeremy Chadwick <koitsu at freebsd.org> wrote:
> On Tue, May 06, 2008 at 12:20:17AM -0500, Matt wrote:
>  > The symptom is as described above - the gvfs-fuse-daemon processes do
>  > not exit cleanly and more processes continue to build-up whenever I
>  > complete an X-session.  The processes do exit when I send them a
>  > manual kill signal.  The only info I have at this point is a backtrace
>  > from a "stuck" process.  Hopefully it will be useful in identifying
>  > the issue.
>
>  What makes it "stuck?"  What state is the process in?  ps or top output
>  would've been helpful, ditto with truss or ktrace output.  Is it eating
>  100% CPU (e.g. read() is continually being called without handling error
>  conditions), or does it just sit there idling?
>
Sorry - should have been more specific than the generic "stuck"
description.  Top shows the process state as "fu_msg" and it is not
consuming any processor resources, just seemingly sits there idling.
Output from ps is:

  UID   PID  PPID CPU PRI NI   VSZ   RSS MWCHAN STAT  TT       TIME COMMAND
 1000  4019     1   0  44  0  6324  2528 -      Ts    ??    0:00.00
/usr/local/libexec//gvfs-fuse-daemon /home/mtosto

Attaching the process with truss when it enters this state (which
happens after I end an X-session) yields no data.  Are there any truss
command line switches that I should try?  I've tried -f, -a and -e.

Attaching the process with ktrace yields very minimal data.  The only
time I can get the process to show something in the trace is when I
attach it with gdb while the trace is running.  When I do that, kdump
shows this:

[mtosto at mtosto-bsd ~]$ kdump
  4019 gvfs-fuse-daemon CALL  read(0x3,0x1055c000,0x21000)
  4019 gvfs-fuse-daemon RET   read RESTART
  4019 gvfs-fuse-daemon CALL  read(0x3,0x1055c000,0x21000)
  4019 gvfs-fuse-daemon RET   read RESTART
  4019 gvfs-fuse-daemon CALL  read(0x3,0x1055c000,0x21000)
  4019 gvfs-fuse-daemon RET   read RESTART
[mtosto at mtosto-bsd ~]$

Each pair of CALL and RET lines represents one attaching of the
process via gdb and executing the bt command within gdb.

The system is a dual-core Opteron running 7.0-RELEASE i386 with the
ULE scheduler.  There does not appear to be any detrimental side
effects to the system with the gvfs-fuse-daemon processes hanging
around.  They just keep stacking up (one for each X-session, so
usually one per day) until I manually kill them off.
>
>
>  > (gdb) bt
>  > #0  0x1045d3d1 in read () from /lib/libc.so.7
>  > #1  0x10379792 in read () from /lib/libthr.so.3
>  > #2  0x1035a67b in fuse_kern_chan_receive (chp=0xbf9fef8c,
>  > buf=0x1055c000 "", size=135168) at fuse_kern_chan.c:28
>  > #3  0x1035fb13 in fuse_chan_recv (chp=0xbf9fef8c, buf=0x1055c000 "",
>  > size=135168) at fuse_session.c:184
>  > #4  0x1035aac6 in fuse_do_work (data=0x10517580) at fuse_loop_mt.c:70
>  > #5  0x1037ab1f in pthread_getprio () from /lib/libthr.so.3
>  > #6  0x00000000 in ?? ()
>