Bug 257012 - Konqueror uses more and more memory
Summary: Konqueror uses more and more memory
Status: CONFIRMED
Alias: None
Product: konqueror
Classification: Applications
Component: khtml (show other bugs)
Version: 4.5.2
Platform: Fedora RPMs Linux
: NOR normal
Target Milestone: ---
Assignee: Konqueror Developers
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2010-11-15 20:28 UTC by yuzyk
Modified: 2015-08-15 08:50 UTC (History)
4 users (show)

See Also:
Latest Commit:
Version Fixed In:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description yuzyk 2010-11-15 20:28:19 UTC
Version:           4.5.2 (using KDE 4.5.2) 
OS:                Linux

I keep a Konqueror session running for general reading, like SlashDot. I open new articles in tabs and close them after. After only a couple days open Konqueror memory usage creeps up even though it mostly sits with a single tab open once I'm done reading. Eventually it shows as the top-most memory-using application. This is pretty old behaviour - since 3.5.x, and would make Konqueror unsuitable for any kiosk-type activity where long up-times are desired.


Reproducible: Always

Steps to Reproduce:
Open a Konqueror session. Read SlashDot or anything by opening links in tabs. Close tabs as you go. Keep the session running for a couple days. 


Actual Results:  
See Konqueror use more and more memory as the session stays open.

Expected Results:  
Konqueror shouldn't use much more memory after a couple days use than right after a new session is created.
Comment 1 Andreas Nordal 2011-01-13 18:09:39 UTC
I use Konqueror 4.5.4 and KDE 4.5.4 (fedora 14). I have 2 GiB RAM + 2 GiB swap.

In my case, memory usage of Konq does not increase monotonically by opening & closing tabs, but there is definately a memory leak along the way since not all memory is released.

I was trying to run the V8 javascript benchmark [1]. The last of the tests supposedly "exercises the automatic memory management". Konqueror failed that test with the mystical text "error" on the page. At that point, Konqueror was consuming >1600 MiB of memory, and 345 MiB of swap was in use (by other processes). When opening an empty "about:blank" tab and closing all others, Konq's memory usage sank to 1333 MiB. Pressing Ctrl-Z to reopen lots of tabs increased memory usage only slightly. I closed Konq normally and observed that a still living "konqueror" process was keeping that 1333 MiB. I opened a new Konqueror, ran the Mozilla javascript benchmark [2] in it, and observed using `htop` that the same "konqueror" instance that used 100% CPU had inherited all that memory. The Mozilla benchmark also failed (after ~20 min when there was 12 tests left), with a popup saying something I understood as "not enough memory". Without noticing exact memory usage, there was hundreds of MiBs RAM left and swap looked untouched. So Konq was not nearly using all memory upon failure.

I closed, killed, and started Konqueror again, then ran the V8 benchmark once again. Memory usage was now pleasingly low and increased monotonically through all tests, including a very noticeable jump moments before the same "error" appeared. Memory usage is still <500 MiB, but won't go away without killing Konq.

References:
1 http://v8.googlecode.com/svn/data/benchmarks/v6/run.html
2 http://dromaeo.com/?all
Comment 2 Dawit Alemayehu 2011-06-09 21:26:02 UTC
Which rendering engine are we talking about here ? khtml or webkit or both ?
Comment 3 yuzyk 2011-06-09 23:50:55 UTC
On Thursday, June 09, 2011 01:26:03 PM Dawit Alemayehu <adawit@kde.org> 
wrote:
> https://bugs.kde.org/show_bug.cgi?id=257012
> 
> 
> Dawit Alemayehu <adawit@kde.org> changed:
> 
>            What    |Removed                     |Added
> ------------------------------------------------------------------------
> ---- CC|                            |adawit@kde.org
> 
> 
> 
> 
> --- Comment #2 from Dawit Alemayehu <adawit kde org>  2011-06-09
> 21:26:02 --- Which rendering engine are we talking about here ? khtml
> or webkit or both ?


KHTML

~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Jerome Yuzyk, Avra Software Lab Inc.
Comment 4 Andreas Nordal 2012-01-15 16:06:07 UTC
I haven't noticed this bug for a while, but...

Try this site (long blog with many pictures):
http://www.tineskreativehjorne.com/

Memory use:
* Firefox: 130 MB
* Konqueror with WebKit: 162 MB
* Konqueror with KHTML, after first having viewed the page in WebKit, closed, killed and reopened it with KHTML: 254 MB
* Konqueror with KHTML, on first visit (or after having emptied its web cache): 1566 MB and still loading, at which point it has slowed down my computer to the point that I cannot even kill it!!!

As the "konqueror" process and its memory use is unaffected by me closing Konqueror, I have to kill it in order to release the memory.
Comment 5 delphi1900 2013-03-20 05:16:46 UTC
Please change the status to confirmed, as I totally confirm this, it's a real pain, I'm hoping this won't be the straw that makes me switch to other browser, because I really love konqueror, and have been using it since 3.0, and wathcing it loose power since 4.0 (specially the file management lost big time - why in God's name isn't konqueror's filemanager just a dolphin kpart, having this duplicated code which is not that frequently updated really lets it down alot, and makes me use konqueror a lot less than I used to ).

Please give this bug a higher priority as it is dead easy to reproduce and it sucks so bad.

Just open konqueror and then open several tabs of youtube videos and play them (either in khtml or webkit) and then close them, but not the window. Open some more, and play them, leave them open for a couple of hours and you'll see the memory konqueros sucks up.
I have plugins loading ondemand, don't know if this information helps. But I do not want flash unless its totally and absolutely necessary, it's awfull
Comment 6 diplosarus 2013-04-20 20:16:01 UTC
*** This bug has been confirmed by popular vote. ***
Comment 7 diplosarus 2015-08-15 08:50:34 UTC
as of 4.14.10 this problem still exists.