289897 - huge memory leak when klipper is running

Status: RESOLVED FIXED

(Core :: Widget: Gtk, defect)

Description

[Marcin Slusarz]

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]

i forgot to mention that konqueror and opera does not have this bug

Comment 2

[Marcin Slusarz]

might be related to Bug 269727

Comment 3

[timeless]

is your gecko based on gtk1 or gtk2?

Comment 4

[Marcin Slusarz]

$ 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]

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]

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]

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]

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]

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]

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]

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)]

Attachment: 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)]

Attachment: 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)]

Attachment: fix leak

Comment 15

[Robert O'Callahan (:roc) (email my personal email if necessary)]

Comment on attachment 218749 [details] [diff] [review]
fix leak

requesting branch approval from shaver, out of desperation

Comment 16

[Darin Fisher]

roc: both patches are the same

Comment 17

[Robert O'Callahan (:roc) (email my personal email if necessary)]

Attachment: fix permissions

Whoopsy-daisy!

Comment 18

[Robert O'Callahan (:roc) (email my personal email if necessary)]

Checked the permissions patch into trunk.

Comment 19

[Daniel Veditz [:dveditz]]

Comment on attachment 218753 [details] [diff] [review]
fix permissions

approved for 1.8.0 branch, a=dveditz for drivers

Comment 20

[Daniel Veditz [:dveditz]]

Comment on attachment 218749 [details] [diff] [review]
fix leak

aproved for 1.8.0 branch, a=dveditz for drivers

Comment 21

[Darin Fisher]

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]

*** Bug 334823 has been marked as a duplicate of this bug. ***

Comment 23

[Worcester12345]

needs mlk key word

Comment 24

[Marcin Slusarz]

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]]

commit leak patch to trunk and both patches into both branches

Comment 26

[Robert O'Callahan (:roc) (email my personal email if necessary)]

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]

(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)]

(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)]

*** Bug 243185 has been marked as a duplicate of this bug. ***