Summary: | kio-http processes take up all CPU/memory, making system unusable. | ||
---|---|---|---|
Product: | [Applications] konqueror | Reporter: | Adam Spragg <adam> |
Component: | general | Assignee: | Konqueror Developers <konq-bugs> |
Status: | RESOLVED DUPLICATE | ||
Severity: | normal | CC: | aseigo, integr8e, kde, neuro |
Priority: | NOR | ||
Version: | 4.2.1 | ||
Target Milestone: | --- | ||
Platform: | Debian testing | ||
OS: | Linux | ||
Latest Commit: | Version Fixed In: | ||
Sentry Crash Report: | |||
Attachments: |
High load, CPU/MEM dominated by kio-http
Still high load, after killing akregator and system is partly usable. strace of busy kio-http process |
Description
Adam Spragg
2009-03-09 01:23:29 UTC
Created attachment 31924 [details]
High load, CPU/MEM dominated by kio-http
Created attachment 31925 [details]
Still high load, after killing akregator and system is partly usable.
Sorry. I'd quit top on that first screenshot. Scrolling back in Konsole, the top line at that point was: top - 23:52:48 up 9 days, 9:52, 3 users, load average: 9.19, 21.04, 28.92 Happened again last night, this time with kde 4.2.2 (Debian unstable). 'top' output below. Went to bed after getting top to run and exitting it. Came back down this morning at around 11, and the plasma clock was displaying 04:20. X completely unresponsive, so switched to text-console to kill akregator and kio-http processes. 'top' told me from there that the load average was around 80. Again, 6 or 7 konqueror windows open, most with only 1 tab. Is there anything I can do to debug this a bit more next time it happens? top - 02:38:50 up 1 day, 17:09, 3 users, load average: 62.08, 65.96, 60.17 Tasks: 210 total, 2 running, 208 sleeping, 0 stopped, 0 zombie Cpu(s): 31.6%us, 1.3%sy, 0.0%ni, 26.2%id, 40.8%wa, 0.0%hi, 0.2%si, 0.0%st Mem: 2052880k total, 2037856k used, 15024k free, 1288k buffers Swap: 979956k total, 979944k used, 12k free, 81640k cached PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND 31529 adam 20 0 244m 78m 2596 S 6 3.9 45:12.21 kio_http 4329 adam 20 0 203m 38m 2560 S 4 1.9 10:46.09 kio_http 2567 adam 20 0 215m 51m 2560 S 4 2.6 19:15.21 kio_http 4266 adam 20 0 204m 39m 2560 S 4 2.0 11:13.74 kio_http 4369 adam 20 0 203m 38m 2560 S 3 1.9 10:41.57 kio_http 4390 adam 20 0 203m 38m 2596 S 3 1.9 10:36.62 kio_http 6599 adam 20 0 192m 29m 2560 S 3 1.5 5:45.34 kio_http 2531 adam 20 0 201m 36m 2596 S 3 1.8 9:55.93 kio_http 4775 adam 20 0 198m 33m 2560 S 3 1.7 7:51.61 kio_http 4833 adam 20 0 189m 24m 2596 S 3 1.2 4:14.41 kio_http 6292 adam 20 0 197m 31m 2564 S 3 1.6 6:22.70 kio_http 6430 adam 20 0 194m 30m 2560 S 3 1.5 6:14.91 kio_http 6634 adam 20 0 192m 29m 2596 S 3 1.5 5:40.28 kio_http 7005 adam 20 0 190m 27m 2560 S 3 1.4 4:52.88 kio_http 12116 adam 20 0 22976 2484 532 S 2 0.1 14:01.46 dbus-daemon 4343 adam 20 0 192m 28m 2560 S 2 1.4 5:37.85 kio_http 6262 adam 20 0 187m 23m 2560 S 2 1.2 3:36.33 kio_http 6470 adam 20 0 194m 30m 2560 S 2 1.5 6:15.61 kio_http 6575 adam 20 0 192m 29m 2560 S 2 1.5 5:47.77 kio_http 7009 adam 20 0 189m 26m 2592 S 2 1.3 4:42.69 kio_http 6526 adam 20 0 186m 23m 2596 S 2 1.2 3:19.43 kio_http 6880 adam 20 0 185m 21m 2560 S 1 1.1 2:59.89 kio_http 12155 adam 20 0 464m 8328 2316 S 1 0.4 9:16.44 kded4 4437 gnunet 20 0 408m 20m 1704 S 1 1.0 29:43.89 gnunetd 10832 root 20 0 754m 147m 2028 D 1 7.4 25:26.55 Xorg 18187 adam 20 0 304m 29m 6356 D 1 1.5 0:02.03 konqueror 209 root 15 -5 0 0 0 D 0 0.0 0:45.04 kswapd0 6252 adam 20 0 454m 46m 1936 S 0 2.3 0:18.87 konqueror 6422 adam 20 0 453m 42m 1936 S 0 2.1 0:21.49 konqueror 6522 adam 20 0 453m 47m 1936 S 0 2.4 0:19.00 konqueror 6593 adam 20 0 469m 62m 1944 S 0 3.1 0:31.78 konqueror 1 root 20 0 10316 588 556 S 0 0.0 0:01.69 init 2 root 15 -5 0 0 0 S 0 0.0 0:00.00 kthreadd 3 root RT -5 0 0 0 S 0 0.0 0:00.02 migration/0 4 root 15 -5 0 0 0 S 0 0.0 0:05.32 ksoftirqd/0 5 root RT -5 0 0 0 S 0 0.0 0:00.00 watchdog/0 i've had similar behaviour with normal, long-lasting sessions in konqueror. The system suddenly started crawling. All I could do was to switch to text console and killall -9 kio_http Created attachment 32890 [details]
strace of busy kio-http process
Just got one particularly busy kio-http process at the moment, so system is mostly usable.
A typical representation of the top few lines of 'top' from the last few minutes is below. The attachment is the output of "strace -tt -p 16711"
Again, if there's anything else I can do to help narrow this down further, I'd be happy to do it. Just let me know what that would be.
top - 16:00:07 up 7 days, 6:31, 2 users, load average: 1.83, 1.97, 2.23
Tasks: 198 total, 4 running, 194 sleeping, 0 stopped, 0 zombie
Cpu(s): 68.8%us, 1.8%sy, 0.0%ni, 29.1%id, 0.0%wa, 0.0%hi, 0.3%si, 0.0%st
Mem: 2052880k total, 2029348k used, 23532k free, 11692k buffers
Swap: 979956k total, 617192k used, 362764k free, 248484k cached
PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND
16711 adam 20 0 384m 216m 6548 S 46 10.8 478:50.00 kio_http
28970 adam 20 0 240m 80m 6500 R 33 4.0 44:03.22 kio_http
28928 adam 20 0 240m 80m 6544 R 32 4.0 44:07.68 kio_http
29003 adam 20 0 224m 63m 6544 S 23 3.2 28:11.26 kio_http
27513 adam 20 0 27656 6320 608 S 3 0.3 26:31.54 dbus-daemon
27553 adam 20 0 476m 15m 7588 S 2 0.8 20:03.50 kded4
4437 gnunet 20 0 410m 24m 1776 S 1 1.2 135:25.77 gnunetd
27668 adam 20 0 526m 49m 14m S 1 2.4 17:00.65 konqueror
28963 adam 20 0 493m 83m 16m S 1 4.2 1:06.45 konqueror
10832 root 20 0 716m 201m 4132 S 1 10.1 119:04.03 Xorg
28994 adam 20 0 457m 63m 16m S 1 3.2 0:47.01 konqueror
I, too, am experiencing this bug running KDE(Mod) 4.2.2 with Qt 4.5.0 on ArchLinux 64-bit (kernel 2.6.29.2). The kio-http KIOSlave seems to propagate while my laptop is mostly dormant, such as when I leave it on while I sleep. I'm not yet sure which process(es) on my system is creating the issue, but will try to determine the root after I'm finished with exams. If somebody would confirm and fix this bug before KDE 4.2.3 or 4.3.0, that would really be awesome! I can also confirm this bug in Fedora 10 (KDE 4.2.3) with kdelibs-4.2.3-2.fc10.x86_64. It happens to me daily now, but I never had this problem until the last few weeks as if a recent update brought this on. *** This bug has been marked as a duplicate of bug 182778 *** |