Date: Sat, 19 Apr 2008 13:26:06 -0400 From: Joe Marcus Clarke <marcus@marcuscom.com> To: Markus Brueffer <markus@freebsd.org> Cc: freebsd-gnome@freebsd.org Subject: Re: Possible problem with gamin Message-ID: <1208625966.38017.5.camel@shumai.marcuscom.com> In-Reply-To: <200804191523.55284.markus@freebsd.org> References: <200804151726.00373.markus@FreeBSD.org> <1208585007.15734.61.camel@shumai.marcuscom.com> <200804191523.55284.markus@freebsd.org>
next in thread | previous in thread | raw e-mail | index | archive | help
--=-9qS2P5RUiBRdPjzDgvDe Content-Type: text/plain Content-Transfer-Encoding: quoted-printable On Sat, 2008-04-19 at 15:23 +0200, Markus Brueffer wrote: > Am Samstag, 19. April 2008 08:03:27 schrieb Joe Marcus Clarke: > > On Tue, 2008-04-15 at 17:25 +0200, Markus Brueffer wrote: > > > Hi, > > > > > > I'm currently hunting down a problem in KDE4 where kded4 (some sort o= f > > > super daemon) hangs when shutting down KDE4. kded4 has a plugin for f= ile > > > monitoring using the FAM API. > > > > > > If I replace gamin with fam, the shutdown works fine, so I'm suspecti= ng a > > > problem with gamin. > > > > > > Attaching to the hanging kded4 process shows this (full backtrace wit= h > > > further debugging data is attached): Can you get a ktrace of both processes when this problem occurs? Joe > > > > > > [Switching to Thread 0x8103100 (LWP 100101)] > > > 0x29976e61 in write () from /lib/libc.so.7 > > > (gdb) bt > > > #0 0x29976e61 in write () from /lib/libc.so.7 > > > #1 0x28fa3152 in write () from /lib/libthr.so.3 > > > #2 0x2977a1f1 in gamin_write_byte (fd=3D13, data=3D0xbfbfd69a "\n", = len=3D10) > > > at gam_api.c:535 > > > #3 0x2977a4b9 in gamin_send_request (type=3DGAM_REQ_CANCEL, fd=3D13, > > > filename=3D0x0, fr=3D0x8254730, userData=3D0x0, data=3D0x811d800, has= _reqnum=3D0) > > > at gam_api.c:629 > > > #4 0x2977bc6d in FAMCancelMonitor (fc=3D0x817acb0, fr=3D0x8254730) a= t > > > gam_api.c:1413 > > > #5 0x281aaca0 in KDirWatchPrivate::removeEntry (this=3D0x817ac50, > > > instance=3D0x81bab60, e=3D0x8254704, sub_entry=3D0x0) > > > at /usr/ports/x11/kdelibs4/work/kdelibs-4.0.3/kio/kio/kdirwatch.cpp:7= 97 > > > #6 0x281a9976 in KDirWatchPrivate::removeEntry (this=3D0x817ac50, > > > instance=3D0x81bab60, _path=3D@0x834beec, sub_entry=3D0x0) > > > at /usr/ports/x11/kdelibs4/work/kdelibs-4.0.3/kio/kio/kdirwatch.cpp:7= 71 > > > #7 0x281a9d56 in KDirWatchPrivate::removeEntries (this=3D0x817ac50, > > > instance=3D0x81bab60) > > > at /usr/ports/x11/kdelibs4/work/kdelibs-4.0.3/kio/kio/kdirwatch.cpp:8= 73 > > > #8 0x281aa017 in ~KDirWatch (this=3D0x81bab60) > > > at /usr/ports/x11/kdelibs4/work/kdelibs-4.0.3/kio/kio/kdirwatch.cpp:1= 520 > > > [...] > > > > > > top(1) shows that both gam_server and kded4 are in 'sbwait' state. > > > > > > This is on RELENG_7 (i386) with gamin-0.1.9_1. Switching between poll= ing > > > and kqueue support doesn't make a difference. > > > > It would be good to see the backtrace from all gam_server threads to ge= t > > an idea what gam_server is doing. kded4 has written data to the > > gam_server socket, and it is blocking until the data is drained. >=20 > Thanks for looking into this. The bt is attached along with matching debu= g=20 > info for kded4. >=20 > I'll leave the system running in this state in case you need more data. >=20 > Thanks, >=20 > Markus --=20 PGP Key : http://www.marcuscom.com/pgp.asc --=-9qS2P5RUiBRdPjzDgvDe Content-Type: application/pgp-signature; name=signature.asc Content-Description: This is a digitally signed message part -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.8 (FreeBSD) iEYEABECAAYFAkgKKy4ACgkQb2iPiv4Uz4eOAwCeLAfnZ7piREGPXJzWVum5OlfE 11YAn28pud8kux2CA6bOlQlKT+vKK4HZ =8l7z -----END PGP SIGNATURE----- --=-9qS2P5RUiBRdPjzDgvDe--
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?1208625966.38017.5.camel>