Last Comment Bug 289897 - huge memory leak when klipper is running
: huge memory leak when klipper is running
Status: RESOLVED FIXED
: fixed1.8.0.4, fixed1.8.1, mlk, privacy
Product: Core
Classification: Components
Component: Widget: Gtk (show other bugs)
: Trunk
: x86 Linux
: -- critical (vote)
: ---
Assigned To: Robert O'Callahan (:roc) (email my personal email if necessary)
:
:
Mentors:
: 243185 (view as bug list)
Depends on:
Blocks: 81122
  Show dependency treegraph
 
Reported: 2005-04-11 06:02 PDT by Marcin Slusarz
Modified: 2006-09-16 20:24 PDT (History)
7 users (show)
mscott: blocking1.8b5-
dveditz: blocking1.8.0.4+
See Also:
Crash Signature:
(edit)
QA Whiteboard:
Iteration: ---
Points: ---
Has Regression Range: ---
Has STR: ---


Attachments
fix as suggested (3.23 KB, patch)
2006-04-17 17:41 PDT, Robert O'Callahan (:roc) (email my personal email if necessary)
no flags Details | Diff | Splinter Review
fix permissions (2.43 KB, patch)
2006-04-17 17:43 PDT, Robert O'Callahan (:roc) (email my personal email if necessary)
no flags Details | Diff | Splinter Review
fix leak (2.43 KB, patch)
2006-04-17 17:44 PDT, Robert O'Callahan (:roc) (email my personal email if necessary)
darin.moz: review+
darin.moz: superreview+
darin.moz: approval‑branch‑1.8.1+
dveditz: approval1.8.0.4+
Details | Diff | Splinter Review
fix permissions (1.22 KB, patch)
2006-04-17 18:05 PDT, Robert O'Callahan (:roc) (email my personal email if necessary)
darin.moz: review+
darin.moz: superreview+
dveditz: approval‑branch‑1.8.1+
dveditz: approval1.8.0.4+
Details | Diff | Splinter Review

Description Marcin Slusarz 2005-04-11 06:02:37 PDT
User-Agent:       Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.7.6) Gecko/20050324 Firefox/1.0.2
Build Identifier: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.7.6) Gecko/20050324 Firefox/1.0.2

mozilla suite AND mozilla firefox on several configurations leaks huge amounts
of memory (2-3 MB/s) when selecting and copying large texts (probably > 500 kB)
it only happens when KDE klipper is running

tested on:
gentoo, amd64, firefox 1.0.2 + kde 3.3
gentoo, amd64, mozilla suite 1.7.6 + kde 3.3

fedora core, x86, firefox 1.0.2 + kde 3.4
slackware, x86, mozilla suite 1.? + kde 3.2
fedora core, x86, mozilla suite 1.? + kde 3.3


Reproducible: Always

Steps to Reproduce:
1. start klipper

2. create big text file:
perl -e '$i=0;while ($i<10000) {print "a" x 99, "\n";$i++;}' > test.txt

3. open it with mozilla or firefox
hit ctrl-a - mozilla starts to take 7% of CPU and 1-2 MB/s

4. hit ctrl-c - load changes to ~15%, memory leaks 2-3 MB/s

Actual Results:  
mozilla took all memory and crashed

Expected Results:  
not to take so much memory ;)

it might be bug in klipper, but mozilla leaks (not klipper), so i decided to
fill a bug here
Comment 1 Marcin Slusarz 2005-04-11 06:05:16 PDT
i forgot to mention that konqueror and opera does not have this bug
Comment 2 Marcin Slusarz 2005-04-28 05:19:54 PDT
might be related to Bug 269727
Comment 3 timeless 2005-08-30 09:53:59 PDT
is your gecko based on gtk1 or gtk2?
Comment 4 Marcin Slusarz 2005-09-01 10:50:26 PDT
$ ldd /usr/lib/mozilla-firefox/firefox-bin | grep gtk
        libgtk-x11-2.0.so.0 => /usr/lib/libgtk-x11-2.0.so.0 (0x00002aaaab4c3000)
$ epm -qf /usr/lib/libgtk-x11-2.0.so
gtk+-2.6.8

right now i've got firefox 1.0.6 and kde 3.4.1 (gentoo, amd64)
Comment 5 Marcin Slusarz 2005-09-04 09:32:39 PDT
official 1.0.6 and latest-mozilla1.8 nightly build also leaks
even when klipper is not alive every ctrl-c creates file clipboardcache-number
in /tmp (of size 2MB if selected file is 1MB) and these files are not deleted
when ff exits
Comment 6 Scott MacGregor 2005-09-13 10:10:29 PDT
no patch, not a regression over 1.0 and not serious enough for us to stop the
release. However it would be nice to get someone working on this, hopefully
someone will for the next release. 
Comment 7 Marcin Slusarz 2005-09-29 15:32:59 PDT
it would be nice if someone with appropriate permissions could "confirm" this
bug, so i could stop checking for status of this bug
Comment 8 Udo Richter 2006-04-13 19:24:16 PDT
I'm seeing this on **Win32**, 
Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8) Gecko/20060413 Firefox/2.0a1 ID:2006041304

Copied large amounts of text into clipboard, and Firefox got extremely slow. With the above sample, every page visit leaked several mbytes of memory and dropped 2mb files %TEMP%\clipboardcace-nnn. 

-> Confirming.
Comment 9 Udo Richter 2006-04-14 09:45:03 PDT
This is triggered if the clipboard contains 500001 bytes or more of plain text. (Win32, LF line endings, CR don't count. This gets doubled because its stored internally as UTF-16.)

One way to trigger this is to copy the text inside firefox. Another way to trigger this is to load pages or switch tabs, but for me this is not triggered by very simple pages. One page that triggers this is http://www.heise.de/newsticker/. In this case, the text just has to be in the clipboard, copied form some other app.

I've verified this with a clean profile and no extensions.

widget/src/xpwidgets/nsTransferable.cpp, DataStruct::kLargeDatasetSize=1000000 seems to be the trigger limit, that also triggers the clipboardcache swap file.

The clipboardcache file leaks since no one seems to delete these files at all. There is a cacheFile->Remove() in DataStruct::~DataStruct() that is commented out and has always been commented out. The leaking memory seems to be a multiple of the clipboard size, so the leak is likely somewhere around the clipboardcache handling.


Some open questions:
- Who is polling the clipboard all the time, and why?
- Why are the clipboardcache files created with mask 755 (rwxr-xr-x)? Clipboard files are private data and shouldn't be world-readable, especially not in a public temp file that is not deleted.

Note: Someone with appropriate rights should set the platform to all/all, component to widget (cross-platform) and should update the summary.
Comment 10 Marcin Slusarz 2006-04-15 11:52:39 PDT
i think this kind of permission (rwxr-xr-x) is a security problem

(this bug is still present in 1.5.0.2)
Comment 11 Darin Fisher 2006-04-17 11:48:14 PDT
File permissions are set here:
http://lxr.mozilla.org/mozilla/source/widget/src/xpwidgets/nsTransferable.cpp#189

Seems like it would be pretty easy to change that to something sane (like 0600).
Comment 12 Robert O'Callahan (:roc) (email my personal email if necessary) 2006-04-17 17:41:53 PDT
Created attachment 218747 [details] [diff] [review]
fix as suggested

That works.

The leak is in ReadCache. It's a pretty bad leak, but simple enough to fix. We should get this on branches.
Comment 13 Robert O'Callahan (:roc) (email my personal email if necessary) 2006-04-17 17:43:39 PDT
Created attachment 218748 [details] [diff] [review]
fix permissions

I guess the right thing to do is to split it up. Here is the permissions fix.
Comment 14 Robert O'Callahan (:roc) (email my personal email if necessary) 2006-04-17 17:44:50 PDT
Created attachment 218749 [details] [diff] [review]
fix leak
Comment 15 Robert O'Callahan (:roc) (email my personal email if necessary) 2006-04-17 17:46:48 PDT
Comment on attachment 218749 [details] [diff] [review]
fix leak

requesting branch approval from shaver, out of desperation
Comment 16 Darin Fisher 2006-04-17 17:49:07 PDT
roc: both patches are the same
Comment 17 Robert O'Callahan (:roc) (email my personal email if necessary) 2006-04-17 18:05:43 PDT
Created attachment 218753 [details] [diff] [review]
fix permissions

Whoopsy-daisy!
Comment 18 Robert O'Callahan (:roc) (email my personal email if necessary) 2006-04-17 18:26:31 PDT
Checked the permissions patch into trunk.
Comment 19 Daniel Veditz [:dveditz] 2006-04-19 12:21:07 PDT
Comment on attachment 218753 [details] [diff] [review]
fix permissions

approved for 1.8.0 branch, a=dveditz for drivers
Comment 20 Daniel Veditz [:dveditz] 2006-04-20 11:39:52 PDT
Comment on attachment 218749 [details] [diff] [review]
fix leak

aproved for 1.8.0 branch, a=dveditz for drivers
Comment 21 Darin Fisher 2006-04-20 11:40:00 PDT
Comment on attachment 218749 [details] [diff] [review]
fix leak

r+sr=darin

hit the branches too!  (a=darin on behalf of drivers)
Comment 22 Eric 2006-04-21 10:42:25 PDT
*** Bug 334823 has been marked as a duplicate of this bug. ***
Comment 23 Worcester12345 2006-04-21 11:50:40 PDT
needs mlk key word
Comment 24 Marcin Slusarz 2006-04-22 04:20:43 PDT
what about those lost clipboardcache files? does any of these patches solve this problem too?

ps: see bug 318069, bug 243185
Comment 25 Wolfgang Rosenauer [:wolfiR] 2006-04-23 23:16:21 PDT
commit leak patch to trunk and both patches into both branches
Comment 26 Robert O'Callahan (:roc) (email my personal email if necessary) 2006-04-24 03:21:02 PDT
Thanks Wolfgang. It's a holiday over here.

Marcin: This does not affect the files. Please file a separate bug about that.
Comment 27 Marcin Slusarz 2006-04-26 09:28:41 PDT
(In reply to comment #26)
> Marcin: This does not affect the files. Please file a separate bug about that.

ok, see bug 335545
Comment 28 Wayne Mery (:wsmwk, NI for questions) 2006-07-17 06:04:49 PDT
(In reply to comment #14)
> Created an attachment (id=218749) [edit]
> fix leak

roc, et al, was leak fix linux-only?
Comment 29 Wayne Mery (:wsmwk, NI for questions) 2006-09-16 20:24:23 PDT
*** Bug 243185 has been marked as a duplicate of this bug. ***

Note You need to log in before you can comment on or make changes to this bug.