Bug 51061 - konqueror excessive memory usage
Summary: konqueror excessive memory usage
Alias: None
Product: konqueror
Classification: Applications
Component: general (show other bugs)
Version: unspecified
Platform: Compiled Sources Linux
: NOR normal (vote)
Target Milestone: ---
Assignee: Konqueror Developers
Depends on:
Reported: 2002-11-22 20:42 UTC by cb-kde
Modified: 2003-07-21 03:08 UTC (History)
1 user (show)

See Also:
Latest Commit:
Version Fixed In:


Note You need to log in before you can comment on or make changes to this bug.
Description cb-kde 2002-11-22 20:42:30 UTC
Version:            (using KDE KDE 3.0.99)
Installed from:    Compiled From Sources
Compiler:          gcc 2.95.4 (debian prerelease) 
OS:          Linux

I use konqueror for long periods of time, and its memory usage gradually increases with time.

When konqueror is loaded, it uses approximately 30MB (which seems like too much, but that's a separate issue). Once konqueror has been used for browsing the web for a while, it can use over 100MB.

Unfortunately, I don't have a specific website which causes this apparent memory leak. I presume that others don't see this level of memory usage, so I speculate that it might be something to do with the way I use it. After browsing a few sites, I always press the back button and hold it down to select the first site I visited. I also frequently press the back button to cancel transfers if a site does not load quickly. Perhaps there's some corner cases which aren't handled correctly. My laptop is only a 333MHz celery with 128MB, so running valgrind is a impractical.

Sorry, this isn't a very useful bug report, but I hope this helps you identify the problem.
Comment 1 cb-kde 2002-11-24 19:49:32 UTC
Subject: Re:  New: konqueror excessive memory usage

I had a smart idea on this. I discovered that I can use dcop to force 
konqueror to browse different pages. I left a script (below) running on my 
server box which simulates a browsing session. I can now reproduce the 
heavy memory usage of konqueror. I used valgrind to try and identify any 
leaks, and it doesn't reveal anything significant (approx 30k leaked, some 
of that by libraries not part of KDE). You might need to run this script a 
few times. I can get Konqueror to consume well over 100MB (based on output 
of top. I also experience severe slow downs and heavy swap usage, so this 
value is entirely believable - I don't think top is being misleading here)

Valgrind reports that the amount of allocated heap memory at the end is 
quite small, in the order of 1MB.

I don't know enough of KDE to speculate what might be using this amount of 
memory. I hope that this script will help the Konqueror developers to 
reproduce and track down the problem. I don't know which configuration 
options are relevant - I will provide any config files which might be 

The script follows. You need to have only 1 instance of konqueror running, 
and it should be freshly loaded. You might need to make the sleep period 
shorter if you have a fast computer and/or a fast internet connection. My 
server machine is a 1.2GHz duron, and the internet link is a 128kbps cable 

(slightly reformatted to deal with line breaks)

KONQ=`dcop |grep '^konqueror-'`

for j in 1 2 3 4 5 6 7 8 9 10
for i in http://slashdot.org/ http://freshmeat.net/ \
http://theregister.co.uk http://news.bbc.co.uk/1/hi.html \ 
http://www.ussg.iu.edu/hypermail/linux/kernel/0211.3/ \ 
http://www.iconbar.com/ http://www.drobe.co.uk/ \
'http://bleb.org/cgi-bin/tv/all.cgi?desc=1&b=1' http://rootprompt.org/ \ 
http://www.debianplanet.org/ http://cnn.com/
  dcop $KONQ qt/konqueror-mainwindow#1/qt_top_dock/locationToolBar/history \
 setProperty currentText "$i"
  dcop $KONQ qt/KXMLGUILClient-KActionCollection/go_url activate
  sleep 3

Comment 2 cb-kde 2002-12-04 20:11:37 UTC
The memory leak seems to be significantly slower if Javascript is disabled. 
Perhaps this script provokes several different memory leaks. 
Comment 3 Dirk Mueller 2003-07-21 03:08:57 UTC
kjs used to produce a big memory leak. this should be fixed with 3.1.