Date: Wed, 7 May 2008 09:19:24 -0500 From: Matt <datahead4@gmail.com> To: "Jeremy Chadwick" <koitsu@freebsd.org> Cc: ports@freebsd.org, amistry@am-productions.biz Subject: Re: FreeBSD Port: fusefs-libs-2.7.2_1 - gvfs-fuse-daemon process(es) stuck Message-ID: <cd6b4a5b0805070719h63a7c507s6e5545b1af4a31c3@mail.gmail.com> In-Reply-To: <20080506053244.GA94936@eos.sc1.parodius.com> References: <cd6b4a5b0805052220i87f274fnd5f08618d9a72fef@mail.gmail.com> <20080506053244.GA94936@eos.sc1.parodius.com>
next in thread | previous in thread | raw e-mail | index | archive | help
On Tue, May 6, 2008 at 12:32 AM, Jeremy Chadwick <koitsu@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@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@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 ?? () >
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?cd6b4a5b0805070719h63a7c507s6e5545b1af4a31c3>