Bug 51965 - uses 95% of my cpu
Summary: uses 95% of my cpu
Status: RESOLVED FIXED
Alias: None
Product: kget
Classification: Applications
Component: general (show other bugs)
Version: 0.8.1
Platform: Compiled Sources Linux
: NOR normal
Target Milestone: ---
Assignee: KGet authors
URL:
Keywords:
: 57251 58726 63460 88822 117793 139016 (view as bug list)
Depends on:
Blocks:
 
Reported: 2002-12-16 08:48 UTC by Helge Hielscher
Modified: 2007-03-30 17:48 UTC (History)
7 users (show)

See Also:
Latest Commit:
Version Fixed In:
Sentry Crash Report:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description cjb 2002-12-16 08:48:58 UTC
Version:            (using KDE KDE 3.0.99)
Installed from:    Compiled From Sources
Compiler:          gcc 3.2 
OS:          Linux

sometimes i'll notice that my computer is running really slowly and laggy.  so i run top to see whats going and kget is using 95% of my cpu even though there are NO items in its window.  whats the deal?  it did this in kde-3.1-rc3 also.

thanks,
christopher
Comment 1 Carsten Pfeiffer 2002-12-16 12:10:48 UTC
What's your kget version? What output do you get of `ps aux | grep kget' 
when it's using so much CPU? 
Comment 2 pch 2002-12-18 17:53:05 UTC
darkmoon@pch $ ps aux | grep kget 
pch      28691 87.6  2.6 72908 16876 ?       R    16:40  48:08 kget -caption KGet -icon kget 
-miniicon kget 
pch      29019  0.0  0.0  1388  476 pts/0    S    17:35   0:00 grep kget 
 
I attach the debugger and i get 3 thread sleeping on  
slave:run() warker.wait() this 3 must not take more that any cpu time 
( i was downloading 3 files so this are my slave threads) 
 
1 thread is the thread manager running on 
pool() in libc.so.6 
 
the last (the only running) on kapp.exec() and is this that is taking 99% of cpu... 
 
 
Comment 3 Phil 2003-02-01 21:29:36 UTC
I have the same problems under v 8.3 ,SUSE 8.1  
Takes up all free cpu when downloading 1 file 
(ftp://ftp.snt.utwente.nl/pub/os/linux/gentoo/releases/1.4_rc2/x86/i686/livecd/gentoo-grp-i686-1.4_rc2.iso)   
 
Phil 
Comment 4 Erik 2003-02-15 23:37:13 UTC
I have the same problem, i saved an .m3u from mp3.com, containing about 140 urls.  
kget took a *long* time to queue up these files, then it finally did, and is now using 50% 
of the CPU, with X using the other 50%.  KGet also has 40M in the RSS part of top(the 
programs memory usage) and 54M in share(memory+libs).  it either suggests kget uses 
a *large* ammount of memory for each item in the queue, or something.  As soon as i 
closed kget X stopped cpu. 
 
Here is current version information 
 
Package: kget 
Version: 4:3.1.0-0woody2 
-- System Information 
Debian Release: 3.0 
Kernel Version: Linux tiger 2.5.59 #1 Wed Feb 12 11:25:37 PST 2003 i686 unknown 
 
Versions of the packages kget depends on: 
ii  kdelibs4       3.1.0-0woody5  KDE core libraries 
ii  libart-2.0-2   2.3.8-1        The Gnome 2 canvas widget - runtime files. 
ii  libc6          2.2.5-11.2     GNU C Library: Shared libraries and Timezone 
ii  libfam0        2.6.6.1-5.2    client library to control the FAM daemon 
ii  libjpeg62      6b-5           The Independent JPEG Group's JPEG runtime li 
ii  libpng3        1.2.1-1.1.wood PNG library - runtime 
ii  libqt3-mt      3.1.1+cvs.2002 Qt GUI Library (Threaded runtime version) 
ii  libstdc++2.10- 2.95.4-11woody The GNU stdc++ library 
ii  xlibs          4.1.0-16       X Window System client libraries 
ii  zlib1g         1.1.4-1        compression library - runtime 
 
 
Comment 5 Carsten Pfeiffer 2003-03-03 13:00:04 UTC
Subject: Re:  uses 95% of my cpu

On Saturday 15 February 2003 23:37, you wrote:

> ------- I have the same problem, i saved an .m3u from mp3.com, containing
> about 140 urls. kget took a *long* time to queue up these files, then it
> finally did, and is now using 50% of the CPU, with X using the other 50%. 
> KGet also has 40M in the RSS part of top(the programs memory usage) and 54M
> in share(memory+libs).  it either suggests kget uses a *large* ammount of
> memory for each item in the queue, or something.  As soon as i closed kget
> X stopped cpu.

I think this is a different problem -- having 140 threads running and 140 
download windows, timers and various other widgets is surely using some RAM 
and CPU (kget currently creates all those things even if it does not show any 
dialog for a download, so there is quite some room for optimization).

Cheers
Carsten Pfeiffer
-----BEGIN PGP SIGNATURE-----

iQEVAwUBPmND5KWgYMJuwmZtAQHnsAgAszA2+GP2ydgF21Pjr3C7GDbg/gFGpLB3
Ji2mhJtYf6CWXc3tel2ct3CGuTCUYvBtJeLyon2p7JSGfMnXwpu6xvcxhhm6VMlL
cn1IEsV1zwKiVsMz/9Qnm+z+eNcwlepY/WGH4VEr8h4/Yh1ryZdRl38efrR9CRgD
F14SXkIJh46kGjCPWMXasGtogUkPKDTt1xJYaLeVvadmmEKX24CAQ3s/Srz8GbbZ
Qe9lAa6wugh68fyxr4hk/DkEZBJFhmsSxQpyF6X2hMkC0DXd93IVarNd11vca4q+
ID84hL5NOnQEUBOzZHoXkAd+ERjHq4cHrZnL0dNMwGmox5RChq4CZQ==
=cJqR
-----END PGP SIGNATURE-----

Comment 6 illogic-al 2003-10-28 17:34:20 UTC
this problem still exists as of latest cvs (10/25/2003)
i didn't have the kget window open and would have totally missed it were it not for the fact that my athlon xp 2000+ temp was at 71C (?) then i checked cpu usage and there was kget right at the top (pun intended)
Comment 7 Amit Shah 2003-11-12 08:25:28 UTC
I saved a webpage on my h/d, konqi started kget and kget sat in the kicker panel after that. It started using 50% of the CPU, not doing anything. The download was complete, and the page was saved. It also used 18% of mem., which is lots. It had consumed around 57:46.59m of time (reported from top), which is just not acceptable. I didn't experience this with <= 3.1.4, just seems to happen with the 3.2beta1.
Comment 8 Christopher J. Bottaro 2004-03-22 21:24:51 UTC
i am >still<  having this problem in kde-3.2.1 compiled from source on a fedora core 1 system.  i am the original poster of this bug (my email has changed since then (a year ago).

to reiterate, sometimes (not everytime), when i download something using kget (via konqeror), it monopolizes my cpu and doesn't give it up even after the download has completed.
Comment 9 Jaime Torres 2004-05-19 11:03:30 UTC
In kde-3.2.2, compiled from source, it consumes too much CPU, and too much memory, up to 200M when it downloads a large file, for example, an iso image. And it only has one file in the queue.
The problem is also that this huge amount of memory is never released, until I kill kget.

Regards.
Comment 10 Stephan Kulow 2004-05-27 10:12:31 UTC
Replaced cjb@cs.utexas.edu with hhielscher@unternehmen.com due to bounces by reporter
Comment 11 Justin Sheckler 2005-06-29 22:25:39 UTC
I can confirm this behavior with both SuSE 9.2, KDE 3.4 and Kubuntu 5.04, KDE 3.4.1.  At this moment KGet is using ~96% CPU, with 2 active downloads and 5 queued.  Sometimes it almost seems as if KGet takes up more CPU when the downloads come through slowly (~2Kbps) than at a normal rate (~50Kbps.)  Memory usage is moderate.

Is KGet still actively maintained?
Comment 12 Andrew Schulman 2005-09-14 10:47:10 UTC
*** This bug has been confirmed by popular vote. ***
Comment 13 Urs Wolfer 2005-09-20 14:08:46 UTC
*** Bug 57251 has been marked as a duplicate of this bug. ***
Comment 14 Urs Wolfer 2005-09-20 14:18:50 UTC
*** Bug 58726 has been marked as a duplicate of this bug. ***
Comment 15 Urs Wolfer 2005-09-20 15:32:37 UTC
*** Bug 63460 has been marked as a duplicate of this bug. ***
Comment 16 Urs Wolfer 2005-09-20 17:01:48 UTC
*** Bug 88822 has been marked as a duplicate of this bug. ***
Comment 17 Ferdinand Gassauer 2005-10-13 18:28:10 UTC
top says (SVN 3.5 branch)

  PID USER      PR  NI  VIRT  RES  SHR S %CPU %MEM    TIME+  COMMAND
32646 kdesvn    25   0  113m  23m  15m R 99.0  4.7  29:58.78 kget
Comment 18 James 2006-02-03 13:31:55 UTC
This still happens with version 0.8.5 which is part of KDE 3.5.0.

I have just downloaded the Windows version of OpenOffice, during which time KGet was consuming 99% of my CPU - despite having closed its window. Now the download has complete, it is still using 99% of my cpu to do nothing...

----
top - 12:29:10 up  1:19,  3 users,  load average: 1.12, 1.25, 0.93
Tasks: 134 total,   3 running, 131 sleeping,   0 stopped,   0 zombie
Cpu(s): 48.6% us, 11.7% sy,  0.0% ni, 39.3% id,  0.0% wa,  0.0% hi,  0.3% si
Mem:    515000k total,   508368k used,     6632k free,    26892k buffers
Swap:   546200k total,      164k used,   546036k free,   144332k cached

  PID USER      PR  NI  VIRT  RES  SHR S %CPU %MEM    TIME+  COMMAND
 6897 james     25   0 28460  16m  12m R 97.4  3.3  12:02.47 kget
----

After closing it and relaunching, kget behaves itself, as this output from PS shows...

james    11689  4.3  2.6  25420 13896 pts/2    S    12:31   0:00 kget
Comment 19 Tap 2006-09-03 04:10:53 UTC
I am on KDE 3.5.4 with KGet 0.8.5 on Linux 2.4.33 and am also experiencing this bug. I don't know what triggers this behavior but strace shows that KGet is constantly looping on select:

select(20, [3 5 6 7 9 13 18 19], [], [], {0, 0}) = 0 (Timeout)
gettimeofday({1157249144, 176307}, NULL) = 0
gettimeofday({1157249144, 176419}, NULL) = 0
ioctl(5, FIONREAD, [0])                 = 0
gettimeofday({1157249144, 177478}, NULL) = 0
select(20, [3 5 6 7 9 13 18 19], [], [], {0, 0}) = 0 (Timeout)
gettimeofday({1157249144, 177746}, NULL) = 0
gettimeofday({1157249144, 177919}, NULL) = 0
ioctl(5, FIONREAD, [0])                 = 0
gettimeofday({1157249144, 178054}, NULL) = 0
select(20, [3 5 6 7 9 13 18 19], [], [], {0, 0}) = 0 (Timeout)

This is unreasonable behavior and is probably a result of the timeout passed to select not being reset somewhere.
Comment 20 Petr Uzel 2006-10-15 19:00:15 UTC
I can confirm this bug on KDE 3.5.5.
Comment 21 Sebastian Turzański 2006-11-15 18:15:57 UTC
i have the same problem on kde 3.5.5 with opensuse rpm
Comment 22 Tommi Tervo 2006-12-20 08:09:51 UTC
*** Bug 139016 has been marked as a duplicate of this bug. ***
Comment 23 Tommi Tervo 2006-12-20 10:49:46 UTC
*** Bug 117793 has been marked as a duplicate of this bug. ***
Comment 24 Urs Wolfer 2007-03-30 17:48:20 UTC
Due to the move from the make_kget_cool branch back into kdenetwork, this issue has been resolved.

For more details about the new KGet please have a look at this page (1st article):
http://commit-digest.org/issues/2007-02-25/