Version: (using KDE KDE 3.2.0) Installed from: Debian stable Packages OS: Linux I've just installed 3.2 from the debian stable packages, and it all runs very very smoothly in the begging. The problem starts after a while when XFree86 cpu usage reaches maximum levels and makes the computer really really slow. Upon killing the kded process everything returns back to normal. What could cause this issue? Thanks, Cirrus P.S. If you would like any more information or things for me to try just say so.
*** This bug has been marked as a duplicate of 74126 ***
This problem is not exactly the same as the one described on 74126. I cannot pinpoint exactly when and how it happens, but I think that kwin doesn't have anything to do with it. Starting a konsole and closing it using the X button, doesn't reproduce this problem. Also the only process that takes up the cpu, is the XFree86 one, and the kded process usage is almost normal.
Same thing here. Debian Woody, upgraded to 3.2 today. CPU suddenly jumps to 100% with XFree86, kwin and kded being the top users at ~30% each. Killing kded releases the load immediately. At least the kded workaround makes it somewhat bearable, though I don't know if killing kded causes any loss of functionality.
Killing kded does cause loss of functionality. For example you might have problems with cookies in konqueror, you will not be able to use kwallet etc. What I usually do is kill the running kded process as soon as I start kde and then run it again. That seems to solve the problem for now. I hope a release of a new qt package will solve the problem pretty soon.
I've also seen this problem on Debian Woody when I installed the stable KDE 3.2.0 packages. I've seen it happen three times so far.
I have an strace of the kded process around the point in time where it starts to use lots of the CPU time if anyone needs it. It's about 10Mb in size (though 300Kb compressed with gzip). I haven't analysed it yet, but thought I should mention it, if it is helpful to anyone else.
I've got an strace as well, but it doesn't seem very helpful (at least to me). I think they point the whole thing goes into a lockup of some kind is this (i'm no expert): gettimeofday({1075906314, 349408}, NULL) = 0 ioctl(4, 0x541b, [0]) = 0 gettimeofday({1075906314, 349492}, NULL) = 0 select(13, [3 4 5 7 11 12], [], [], {0, 46306}) = 0 (Timeout) gettimeofday({1075906314, 393347}, NULL) = 0 ioctl(4, 0x541b, [0]) = 0 gettimeofday({1075906314, 393431}, NULL) = 0 select(13, [3 4 5 7 11 12], [], [], {0, 2367}) = 0 (Timeout) gettimeofday({1075906314, 403606}, NULL) = 0 gettimeofday({1075906314, 403661}, NULL) = 0 ioctl(4, 0x541b, [0]) = 0 gettimeofday({1075906314, 403737}, NULL) = 0 select(13, [3 4 5 7 11 12], [], [], {0, 42061}) = 0 (Timeout) gettimeofday({1075906314, 453578}, NULL) = 0 gettimeofday({1075906314, 453631}, NULL) = 0 ioctl(4, 0x541b, [0]) = 0 gettimeofday({1075906314, 453705}, NULL) = 0 select(13, [3 4 5 7 11 12], [], [], {0, 42093}) = 0 (Timeout) gettimeofday({1075906314, 503293}, NULL) = 0 gettimeofday({1075906314, 503345}, NULL) = 0 ioctl(4, 0x541b, [0]) = 0 gettimeofday({1075906314, 503420}, NULL) = 0 select(13, [3 4 5 7 11 12], [], [], {0, 42378}) = 1 (in [4], left {0, 20000}) gettimeofday({1075906314, 538873}, NULL) = 0 ioctl(4, 0x541b, [96]) = 0 read(4, "\v\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0"..., 96) = 96 ioctl(4, 0x541b, [0]) = 0 ioctl(4, 0x541b, [0]) = 0 gettimeofday({1075906314, 539134}, NULL) = 0 select(13, [3 4 5 7 11 12], [], [], {0, 6664}) = 1 (in [4], left {0, 10000}) gettimeofday({1075906314, 547275}, NULL) = 0 gettimeofday({1075906314, 547337}, NULL) = 0 ioctl(4, 0x541b, [128]) = 0 read(4, "\34\342Y\25\263\0\0\0!\1\0\0\33\2029\0\0\370\377\277>M"..., 128) = 128 ioctl(4, 0x541b, [0]) = 0 ioctl(4, 0x541b, [0]) = 0 gettimeofday({1075906314, 547551}, NULL) = 0 select(13, [3 4 5 7 11 12], [], [], {0, 48247}) = 1 (in [4], left {0, 40000}) gettimeofday({1075906314, 594818}, NULL) = 0 ioctl(4, 0x541b, [320]) = 0 read(4, "\26\0Y\25\263\0\0\0\200O\2\1\2251\1\1\370\0\200\0\0\004"..., 320) = 320 ioctl(4, 0x541b, [0]) = 0 ioctl(4, 0x541b, [0]) = 0 ioctl(4, 0x541b, [0]) = 0 gettimeofday({1075906314, 595141}, NULL) = 0 select(13, [3 4 5 7 11 12], [], [], {0, 657}) = 1 (in [4], left {0, 10000}) gettimeofday({1075906314, 598740}, NULL) = 0 gettimeofday({1075906314, 598800}, NULL) = 0 ioctl(4, 0x541b, [64]) = 0 read(4, "\22\364Y\25\7\1`\1\324\242b\1\0\361l@8\360P\0108\360P\10"..., 64) = 64 ioctl(4, 0x541b, [0]) = 0 ioctl(4, 0x541b, [0]) = 0 gettimeofday({1075906314, 599042}, NULL) = 0 select(13, [3 4 5 7 11 12], [], [], {0, 46756}) = 1 (in [4], left {0, 40000}) gettimeofday({1075906314, 605852}, NULL) = 0 ioctl(4, 0x541b, [32]) = 0 read(4, "\34\342Y\25\263\0\0\0!\1\0\0[\2029\0\0\370\377\277>M\v"..., 32) = 32 ioctl(4, 0x541b, [0]) = 0 ioctl(4, 0x541b, [0]) = 0 gettimeofday({1075906314, 606084}, NULL) = 0 select(13, [3 4 5 7 11 12], [], [], {0, 39714}) = 0 (Timeout) gettimeofday({1075906314, 646302}, NULL) = 0 gettimeofday({1075906314, 646365}, NULL) = 0 ioctl(4, 0x541b, [0]) = 0 gettimeofday({1075906314, 646443}, NULL) = 0 select(13, [3 4 5 7 11 12], [], [], {0, 49355}) = 1 (in [3], left {0, 40000}) select(4, [3], NULL, NULL, {0, 0}) = 1 (in [3], left {0, 0}) read(3, "\2\1\0\2S\0\0\0", 8) = 8 read(3, "\1\0\0\0", 4) = 4 read(3, "\0\0\0\vDCOPServer\0\0\0\0\1\0\0\0\0\1\0\0\0\0\35app"..., 83) = 83 gettimeofday({1075906314, 656478}, NULL) = 0 ioctl(4, 0x541b, [0]) = 0 gettimeofday({1075906314, 656554}, NULL) = 0 select(13, [3 4 5 7 11 12], [], [], {0, 39244}) = 1 (in [3], left {0, 30000}) select(4, [3], NULL, NULL, {0, 0}) = 1 (in [3], left {0, 0}) read(3, "\2\1\0\2Q\0\0\0", 8) = 8 read(3, "\1\0\0\0", 4) = 4 read(3, "\0\0\0\vDCOPServer\0\0\0\0\1\0\0\0\0\1\0\0\0\0\35app"..., 81) = 81 gettimeofday({1075906314, 664637}, NULL) = 0 ioctl(4, 0x541b, [0]) = 0 gettimeofday({1075906314, 664714}, NULL) = 0 select(13, [3 4 5 7 11 12], [], [], {0, 31084}) = 1 (in [3], left {0, 40000}) select(4, [3], NULL, NULL, {0, 0}) = 1 (in [3], left {0, 0}) read(3, "\2\2\0\2t\0\0\0", 8) = 8 read(3, "\263\0\0\0", 4) = 4 read(3, "\0\0\0\17konqueror-1291\0\0\0\0\5kded\0\0\0\0\20"..., 116) = 116 write(3, "\2\3\2\0*\0\0\0\263\0\0\0", 12) = 12 write(3, "\0\0\0\5kded\0\0\0\0\17konqueror-1291\0\0\0\0\5"..., 41) = 41 write(3, "\1", 1) = 1 gettimeofday({1075906314, 667766}, NULL) = 0 ioctl(4, 0x541b, [0]) = 0 gettimeofday({1075906314, 667848}, NULL) = 0 select(13, [3 4 5 7 11 12], [], [], {0, 27950}) = 1 (in [3], left {0, 30000}) select(4, [3], NULL, NULL, {0, 0}) = 1 (in [3], left {0, 0}) read(3, "\2\1\0\2N\0\0\0", 8) = 8 read(3, "\1\0\0\0", 4) = 4 read(3, "\0\0\0\17konqueror-1291\0\0\0\0\5kded\0\0\0\0\5"..., 78) = 78 gettimeofday({1075906314, 668673}, NULL) = 0 gettimeofday({1075906314, 668761}, NULL) = 0 ioctl(4, 0x541b, [0]) = 0 gettimeofday({1075906314, 668841}, NULL) = 0 select(13, [3 4 5 7 11 12], [], [], {0, 26957}) = 1 (in [4], left {0, 20000}) gettimeofday({1075906314, 675858}, NULL) = 0 ioctl(4, 0x541b, [704]) = 0 read(4, "\21\370Y\25\263\0\0\0\323\n\200\2\1\0\0\300\320\221\353"..., 704) = 704 write(4, "\31\0\v\0\263\0\0\0\0\0\30\0! ~@\263\0\0\0\v\1\0\0\371"..., 44) = 44 ioctl(4, 0x541b, [32]) = 0 After which point the following messages continuesly repeat until kded is killed: read(4, "\241 Z\25\263\0\0\0\v\1\0\0\371\0\0\0\21\2029\0\5\0\200"..., 32) = 32 write(4, "\31\0\v\0\263\0\0\0\0\0\30\0! ~@\263\0\0\0\v\1\0\0\371"..., 44) = 44 ioctl(4, 0x541b, [32])
Created attachment 4548 [details] 0008-loop_of_death.patch Can you check if Qt has 0008-loop_of_death.patch applied? Attached to the bugreport for your convenience. If not, does applying this patch solve the problem?
Yes the patch does seem to solve the problem. I haven't done extensive testing, but it all runs smooth so far, so I guess its all ok. I've created packages from the original kde ones with the patch. If anyone wants them, just give me a shout. Cheers for the help.
OK as I've had a few people sending me an email for a copy of the packages you can grab them here: http://www.cirrus.eurobell.co.uk/qt/ They can serve as a temporary solution, until some official packages came out. If you have any problems with the packages don't hesitate to email me. John
Above URL contains broken links (404s). Can you please update?
Hm. Yes you are right sorry about that. It was working when I uploaded them. It seems the files got somehow deleted from the server (probably quota reasons). Anyway you can grab them from here for now: http://the-penguin.8bit.co.uk/qt/ . Can someone mirror them in a more reliable server, cause I don't know for how long this one will last. Cheers
I believe the set of packages you have uploaded now is incomplete. The files - libqt3-mt_3.2.1-5woody6_i386.deb - libqt3_3.2.1-5woody6_i386.deb - qt3-designer_3.2.1-5woody6_i386.deb - qt3-doc_3.2.1-5woody6_all.deb are missing. They were on your original download page, and are also in the MD5SUM file. I'd be glad to try them out and provide another mirror at http://www.scsy.de/~mas/sw/qt-loop-of-death/, but it seems they're incomplete at the moment.
Damn, this free hosting providers, they keep deleting my files. I've just finished uploading them once again on the previous site, and just 3 minutes later they were deleted. Ok here should be just ok: http://www.zen34434.zen.co.uk/ . Sorry again. Thanks Cirrus
A mirror up at ftp://projects.gasperino.org/qt/
Thanks, that seems to have fixed it! German mirror at above URL.
*** Bug 74684 has been marked as a duplicate of this bug. ***