Version: (using KDE KDE 3.3.1) Installed from: RedHat RPMs Compiler: gcc version 3.3.3 20040412 (Red Hat Linux 3.3.3-7) Configured with: ../configure --prefix=/usr --mandir=/usr/share/man --infodir=/usr/share/info --enable-shared --enable-threads=posix --disable-checking --disable-libunwind-exceptions --with-system-zlib --enable-__cxa_atexit --host=x86_64-redhat-linux OS: Linux Fedora 2 (x86_64) I compiled the src rpm files from download.kde.org using this command: rpmbuild --rebuild --target x86_64 kdeapp-src.rpm here is lst lines of srtace kded I read somewhere in kde bugs database that this also causes my konqueror to to be able to contact "cookie handler service". $ strace kded stat("/home/saqer/.kde/share/config/", {st_mode=S_IFDIR|0700, st_size=4096, ...}) = 0 access("/home/saqer/.kde/share/config/kdebugrc", W_OK) = -1 ENOENT (No such file or directory) access("/home/saqer/.kde/share/config/kdebugrc", F_OK) = -1 ENOENT (No such file or directory) access("/home/saqer/.kde/share/config", W_OK) = 0 lstat("/home/saqer/.kde/share/config/kdebugrc", 0x533c40) = -1 ENOENT (No such file or directory) stat("/home/saqer/.kde/share/config/kdebugrc", 0x533c40) = -1 ENOENT (No such file or directory) lstat("/home/saqer/.kde/share/config/kdebugrc", 0x533c40) = -1 ENOENT (No such file or directory) stat("/home/saqer/.kde/share/config/kdebugrc", 0x533c40) = -1 ENOENT (No such file or directory) stat("/home/saqer/.kde/share/config/kdebugrc", 0x7fbfffd590) = -1 ENOENT (No such file or directory) stat("/usr/share/config/kdebugrc", ICE default IO error handler doing an exit(), pid = 18590, errno = 9 {st_mode=S_IFREG|0644, st_size=2084, ...}) = 0 --- SIGCHLD (Child exited) @ 0 (0) --- open("/usr/share/config/kdebugrc", O_RDONLY) = 4 fstat(4, {st_mode=S_IFREG|0644, st_size=2084, ...}) = 0 fstat(4, {st_mode=S_IFREG|0644, st_size=2084, ...}) = 0 mmap(NULL, 2084, PROT_READ, MAP_PRIVATE, 4, 0) = 0x2a95557000 fstat(4, {st_mode=S_IFREG|0644, st_size=2084, ...}) = 0 rt_sigaction(SIGBUS, {0x3d0df18e30, [], SA_ONESHOT|0x4000000}, {SIG_DFL}, 8) = 0 rt_sigprocmask(SIG_BLOCK, NULL, [], 8) = 0 fstat(4, {st_mode=S_IFREG|0644, st_size=2084, ...}) = 0 munmap(0x2a95557000, 2084) = 0 rt_sigaction(SIGBUS, {SIG_DFL}, NULL, 8) = 0 close(4) = 0 close(3) = 0 exit_group(255) = ?
*** Bug 92227 has been marked as a duplicate of this bug. ***
*** Bug 92217 has been marked as a duplicate of this bug. ***
I have uninstalled kde-3.3.1 and installed instead kde-3.3.0 from Fedora developement tree. I still experience the same problem. I did not have this problem with kde-3.2*
see comment on bug 83320
I have this problem on FC2 x86_64, with the KDE packages from the KDE Redhat Project. $ kded --version Qt: 3.3.3 KDE: 3.3.2-1.2.2.kde KDE Daemon: $Id: kded.cpp,v 1.94 2004/07/15 13:28:55 lunakl Exp $ The bug is quite reproducible. If I do $ strace kded --nofork --sync The end of the trace is as follows: select(11, [10], NULL, NULL, {0, 0}) = 1 (in [10], left {0, 0}) read(10, "\0\0\0\26e67 /usr/share/gnome\n\0\0\0\0\te6"..., 3000) = 202 select(11, [10], NULL, NULL, {0, 0}) = 0 (Timeout) select(11, [10], NULL, NULL, {0, 0}) = 0 (Timeout) access("/usr/share/gnome/apps", F_OK) = -1 ENOENT (No such file or directory) stat("/usr/share/gnome/capplets", 0x7fbfffee50) = -1 ENOENT (No such file or directory) fcntl(3, 0x402 /* F_??? */, 0x8000001c) = -1 ENOTDIR (Not a directory) close(3) = 0 stat("/", {st_mode=S_IFDIR|0755, st_size=600, ...}) = 0 stat("/usr/share/gnome", {st_mode=S_IFDIR|0755, st_size=272, ...}) = 0 select(11, [10], NULL, NULL, {0, 0}) = 0 (Timeout) access("/usr/share/gnome/capplets", F_OK) = -1 ENOENT (No such file or directory) access("/home/mikb/.kde/share/apps/kconf_update", F_OK) = 0 lstat("/home/mikb/.kde/share/apps/kconf_update", {st_mode=S_IFDIR|0700, st_size=80, ...}) = 0 access("/usr/share/apps/kconf_update", F_OK) = 0 lstat("/usr/share/apps/kconf_update", {st_mode=S_IFDIR|0755, st_size=3312, ...}) = 0 stat("/home/mikb/.kde/share/apps/kconf_update", {st_mode=S_IFDIR|0700, st_size=80, ...}) = 0 open("/proc/sys/kernel/ngroups_max", O_RDONLY) = 3 read(3, "65536\n", 31) = 6 close(3) = 0 mmap(NULL, 266240, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0x2a982ad000 getgroups(65536, [500]) = 1 geteuid() = 500 write(10, "\0\0\0005", 4) = 4 write(10, "M68 500 500 /home/mikb/.kde/shar"..., 53) = 53 munmap(0x2a982ad000, 266240) = 0 select(11, [10], NULL, NULL, {0, 0}) = 1 (in [10], left {0, 0}) read(10, "\0\0\0-e68 /home/mikb/.kde/share/ap"..., 3000) = 118 select(11, [10], NULL, NULL, {0, 0}) = 0 (Timeout) stat("/usr/share/apps/kconf_update", {st_mode=S_IFDIR|0755, st_size=3312, ...}) = 0 open("/proc/sys/kernel/ngroups_max", O_RDONLY) = 3 read(3, "65536\n", 31) = 6 close(3) = 0 mmap(NULL, 266240, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0x2a982ad000 getgroups(65536, [500]) = 1 geteuid() = 500 write(10, "\0\0\0*", 4) = 4 write(10, "M69 500 500 /usr/share/apps/kcon"..., 42) = 42 munmap(0x2a982ad000, 266240) = 0 select(11, [10], NULL, NULL, {0, 0}) = 1 (in [10], left {0, 0}) read(10, "\0\0\0\"e69 /usr/share/apps/kconf_up"..., 3000) = 2598 select(11, [10], NULL, NULL, {0, 0}) = 0 (Timeout) write(3, "\1\2\1\0\255\0\0\0\364\0\0\0", 12) = -1 EBADF (Bad file descriptor) write(2, "ICE default IO error handler doi"..., 69ICE default IO error handler doing an exit(), pid = 29767, errno = 9
Mike: Can you attach the complete strace? Something in kded seems to close the file descriptor of the X Server connection, that's really weird. The top of the strace points to KDirWatch because fcntl(3, 0x402 /* F_??? */, 0x8000001c) seems to be fcntl(e->dn_fd, F_NOTIFY, mask) in kdirwatch.cpp line 571 Does the attach patch fix the problem?
Created attachment 9143 [details] kdirwatch patch
Created attachment 9147 [details] strace of unforked kded start, illustrates failure on x86_64 Waldo, Attached is the full strace of the failure. KDE seems to fail in multifarious ways with out kded, so this is getting annoying! I have only seen this problem with x86_64. I had a very similar setup on my old P3 laptop (FC2, kde-redhat RPMs) and never saw this problem. Regards, Mike
Mike: Based on the trace I think that the patch in #7 fixes the problem.