From owner-freebsd-ports@FreeBSD.ORG Wed May 7 14:19:29 2008 Return-Path: Delivered-To: ports@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 446661065670 for ; Wed, 7 May 2008 14:19:29 +0000 (UTC) (envelope-from datahead4@gmail.com) Received: from wf-out-1314.google.com (wf-out-1314.google.com [209.85.200.170]) by mx1.freebsd.org (Postfix) with ESMTP id 160F18FC16 for ; Wed, 7 May 2008 14:19:28 +0000 (UTC) (envelope-from datahead4@gmail.com) Received: by wf-out-1314.google.com with SMTP id 28so267164wfa.7 for ; Wed, 07 May 2008 07:19:28 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; bh=wGgXfRcSJz6448DBRQvOJOmC0jDcX3GfQ+vkC5Dsbco=; b=mu4+v5oGj6ZzYpMZm/4yN9gzVxO6Zv2t1KhJBoHXS7UQU/msKV1ZsaDiYVrCh9bC5zP6wxiqJfN/r1EVs/GmMPSyipErjUI7egYQ0FTfHZzeKIWRa60ztx6bzStuGHVFMUqQW0jWMJHKs6TGzYwbEe5r0PZB46LDAay7IMRnDGY= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=OOZAsZlFkfx/Gyf60oCazvhFkzRtUJqrzvaAo7+exnNpLen3ts1wvQGNHHxzA3vE0a+iGZQfsLe41bFgfFgUqg/gm6at5L88Z53L1jDoAZ631FfvzN07E0OeKBuNFp5FFefsL+QGuHg50Lftg4q3Bp2Yf4+qvu0fGrw7ZukOHj0= Received: by 10.142.171.6 with SMTP id t6mr894216wfe.173.1210169968400; Wed, 07 May 2008 07:19:28 -0700 (PDT) Received: by 10.143.122.6 with HTTP; Wed, 7 May 2008 07:19:24 -0700 (PDT) Message-ID: Date: Wed, 7 May 2008 09:19:24 -0500 From: Matt To: "Jeremy Chadwick" In-Reply-To: <20080506053244.GA94936@eos.sc1.parodius.com> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline References: <20080506053244.GA94936@eos.sc1.parodius.com> Cc: ports@freebsd.org, amistry@am-productions.biz Subject: Re: FreeBSD Port: fusefs-libs-2.7.2_1 - gvfs-fuse-daemon process(es) stuck X-BeenThere: freebsd-ports@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Porting software to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 07 May 2008 14:19:29 -0000 On Tue, May 6, 2008 at 12:32 AM, Jeremy Chadwick 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 ?? () >