Possible problem with gamin
Joe Marcus Clarke
marcus at marcuscom.com
Sat Apr 19 06:03:33 UTC 2008
On Tue, 2008-04-15 at 17:25 +0200, Markus Brueffer wrote:
> I'm currently hunting down a problem in KDE4 where kded4 (some sort of super
> daemon) hangs when shutting down KDE4. kded4 has a plugin for file monitoring
> using the FAM API.
> If I replace gamin with fam, the shutdown works fine, so I'm suspecting a
> problem with gamin.
> Attaching to the hanging kded4 process shows this (full backtrace with further
> debugging data is attached):
> [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=13, data=0xbfbfd69a "\n", len=10) at
> #3 0x2977a4b9 in gamin_send_request (type=GAM_REQ_CANCEL, fd=13,
> filename=0x0, fr=0x8254730, userData=0x0, data=0x811d800, has_reqnum=0) at
> #4 0x2977bc6d in FAMCancelMonitor (fc=0x817acb0, fr=0x8254730) at
> #5 0x281aaca0 in KDirWatchPrivate::removeEntry (this=0x817ac50,
> instance=0x81bab60, e=0x8254704, sub_entry=0x0)
> at /usr/ports/x11/kdelibs4/work/kdelibs-4.0.3/kio/kio/kdirwatch.cpp:797
> #6 0x281a9976 in KDirWatchPrivate::removeEntry (this=0x817ac50,
> instance=0x81bab60, _path=@0x834beec, sub_entry=0x0)
> at /usr/ports/x11/kdelibs4/work/kdelibs-4.0.3/kio/kio/kdirwatch.cpp:771
> #7 0x281a9d56 in KDirWatchPrivate::removeEntries (this=0x817ac50,
> at /usr/ports/x11/kdelibs4/work/kdelibs-4.0.3/kio/kio/kdirwatch.cpp:873
> #8 0x281aa017 in ~KDirWatch (this=0x81bab60)
> at /usr/ports/x11/kdelibs4/work/kdelibs-4.0.3/kio/kio/kdirwatch.cpp:1520
> 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 polling and
> kqueue support doesn't make a difference.
It would be good to see the backtrace from all gam_server threads to get
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.
> Any ideas?
PGP Key : http://www.marcuscom.com/pgp.asc
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Size: 195 bytes
Desc: This is a digitally signed message part
Url : http://lists.freebsd.org/pipermail/freebsd-gnome/attachments/20080419/6d417d35/attachment.pgp
More information about the freebsd-gnome