Version: 0.12.3 (using KDE KDE 3.5.5) Installed from: Gentoo Packages Compiler: 4.1.1 OS: Linux Well, first, this resembles #124936. Problem is, I didn't change much expect installing new KDE software which doesn't seem to interfere with Kopete (Kaffeine is such an example). Everything always worked great with this version. No problems. Suddently, 99% I send a message I get Kopete eating 100% of the CPU for 15-20secs. I thought it had to do with my history or my preferences, so I started a new Linux account and started Kopete in a fresh environment, but same thing happens. I so decided to strace kopete, but it seems it would be harder than that due to the huge amount of processes spawn by kopete (8 in my case to be exact). So I traced the 8 processes in my monitor. Some of them were terminated with exit(0) even before I was able to send a message. So I sent a message and kabuummmm, one of the processes just went crazy with messages as follows: mmap2(NULL, 528384, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0xb4a68000 munmap(0xb45ea000, 528384) = 0 mmap2(NULL, 528384, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0xb45ea000 There's a sequence of about 15700 messages similar to this one when the cpu goes to 100%. And I thought... the only thing I did was join the different users I add into a single one when they were the same personal because only recently I learned about meta-contacts, however, I'm not certain that this bug happened right after the change. Still, renders Kopete unusable. :-( If you wish I can send you the whole 400000 lines of strace for the process. Hope I can give you more info if you need.
Persists in 0.12.4!
what plugins are enabled?
I can't confirm this, anybody else having this problem?
I still confirm this. Tex plugin is installed but it is not used. It happens even with it off.
if you still have the strace or can make a new one, please attached a compressed version to this bug report.
Waiting on an strace output file to be attached to the bug report. If you're still having the problem, please attach an strace output log to this bug report and reopen it. Also, when you capture the output, please be sure to pass the --nofork option to kopete so it doesn't create multiple processes that need to be traced.
Since a few day my KDE behaves the same. (3.5.10 "release 27.1", Linux kernel 2.6.22.18-0.2-default, openSUSE 10.3) I'll add an attachment with a compressed output of "strace -v kopete -nofork >& kopete-startup.strace.txt". Kopete takes some minutes to start and some minutes to quit. The same applies to kontact or kmail. One thing in the trace makes me think: ... lstat64("/home", {st_dev=makedev(8, 4), st_ino=2, st_mode=S_IFDIR|0755, st_nlink=6, st_uid=0, st_gid=0, st_blksize=4096, st_blocks=8, st_size=4096, st_atime=2008/10/09-17:43:39, st_mtime=2008/10/08-16:21:24, st_ctime=2008/10/08-16:21:24}) = 0 ... Why calling stat on the "/home" directory and not my user's home? If "makedev" indicates a request to create something inside the file system, its no wonder that it fails. My user doesn't have permission to write there. There is a similar thread for Kubuntu here: http://ubuntuforums.org/showthread.php?t=783375 See comment #8. Unfortunately, my std.cvf appears to be fine (i'm telling by inspecting it with "less").
Created attachment 27767 [details] Bzip2 compressed strace output. I interrupted kopete manually after some minutes waiting on the application to quit.
I upgraded to a newer distro (fresh install but keeping user's home as-is) and the effect goes away.
...and here it is again. The bug is here again. Just since I upgraded my KDE 3.5.9 to 3.5.10.