The default bug view has changed. See this FAQ.

huge memory leak when klipper is running

RESOLVED FIXED

Status

()

Core
Widget: Gtk
--
critical
RESOLVED FIXED
12 years ago
11 years ago

People

(Reporter: Marcin Slusarz, Assigned: roc)

Tracking

(4 keywords)

Trunk
x86
Linux
fixed1.8.0.4, fixed1.8.1, mlk, privacy
Points:
---
Bug Flags:
blocking1.8b5 -
blocking1.8.0.4 +

Firefox Tracking Flags

(Not tracked)

Details

Attachments

(2 attachments, 2 obsolete attachments)

(Reporter)

Description

12 years ago
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
(Reporter)

Comment 1

12 years ago
i forgot to mention that konqueror and opera does not have this bug
(Reporter)

Comment 2

12 years ago
might be related to Bug 269727
(Reporter)

Updated

12 years ago
Summary: memory leak when klipper is running → huge memory leak when klipper is running
(Reporter)

Updated

12 years ago
Blocks: 81122

Comment 3

12 years ago
is your gecko based on gtk1 or gtk2?
Assignee: selection → blizzard
Component: Selection → Widget: Gtk
QA Contact: gtk
(Reporter)

Comment 4

12 years ago
$ 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)
(Reporter)

Comment 5

12 years ago
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
Flags: blocking1.8b5?

Comment 6

12 years ago
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. 
Flags: blocking1.8b5? → blocking1.8b5-
(Reporter)

Comment 7

12 years ago
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

11 years ago
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.
Status: UNCONFIRMED → NEW
Ever confirmed: true

Comment 9

11 years ago
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.
(Reporter)

Comment 10

11 years ago
i think this kind of permission (rwxr-xr-x) is a security problem

(this bug is still present in 1.5.0.2)
Flags: blocking1.8.0.3?
Keywords: privacy

Comment 11

11 years ago
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).
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.
Assignee: blizzard → roc
Status: NEW → ASSIGNED
Attachment #218747 - Flags: superreview?
Attachment #218747 - Flags: review?
Attachment #218747 - Flags: approval-branch-1.8.1?
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.
Attachment #218747 - Attachment is obsolete: true
Attachment #218748 - Flags: superreview?(darin)
Attachment #218748 - Flags: review?(darin)
Attachment #218747 - Flags: superreview?
Attachment #218747 - Flags: review?
Attachment #218747 - Flags: approval-branch-1.8.1?
Created attachment 218749 [details] [diff] [review]
fix leak
Attachment #218749 - Flags: review?
Comment on attachment 218749 [details] [diff] [review]
fix leak

requesting branch approval from shaver, out of desperation
Attachment #218749 - Flags: review?(timeless)
Attachment #218749 - Flags: review?
Attachment #218749 - Flags: approval1.8.0.3?
Attachment #218749 - Flags: approval-branch-1.8.1?(shaver)
Attachment #218748 - Flags: approval1.8.0.3?
Attachment #218748 - Flags: approval-branch-1.8.1?(shaver)

Comment 16

11 years ago
roc: both patches are the same
Created attachment 218753 [details] [diff] [review]
fix permissions

Whoopsy-daisy!
Attachment #218748 - Attachment is obsolete: true
Attachment #218753 - Flags: superreview?(darin)
Attachment #218753 - Flags: review?(darin)
Attachment #218753 - Flags: approval1.8.0.3?
Attachment #218753 - Flags: approval-branch-1.8.1?(shaver)
Attachment #218748 - Flags: superreview?(darin)
Attachment #218748 - Flags: review?(darin)
Attachment #218748 - Flags: approval1.8.0.3?
Attachment #218748 - Flags: approval-branch-1.8.1?(shaver)

Updated

11 years ago
Attachment #218753 - Flags: superreview?(darin)
Attachment #218753 - Flags: superreview+
Attachment #218753 - Flags: review?(darin)
Attachment #218753 - Flags: review+
Checked the permissions patch into trunk.
Comment on attachment 218753 [details] [diff] [review]
fix permissions

approved for 1.8.0 branch, a=dveditz for drivers
Attachment #218753 - Flags: approval1.8.0.3?
Attachment #218753 - Flags: approval1.8.0.3+
Attachment #218753 - Flags: approval-branch-1.8.1?(shaver)
Attachment #218753 - Flags: approval-branch-1.8.1+
Comment on attachment 218749 [details] [diff] [review]
fix leak

aproved for 1.8.0 branch, a=dveditz for drivers
Attachment #218749 - Flags: approval1.8.0.3? → approval1.8.0.3+

Comment 21

11 years ago
Comment on attachment 218749 [details] [diff] [review]
fix leak

r+sr=darin

hit the branches too!  (a=darin on behalf of drivers)
Attachment #218749 - Flags: superreview+
Attachment #218749 - Flags: review?(timeless)
Attachment #218749 - Flags: review+
Attachment #218749 - Flags: approval-branch-1.8.1?(shaver)
Attachment #218749 - Flags: approval-branch-1.8.1+
Flags: blocking1.8.0.3? → blocking1.8.0.3+

Comment 22

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

Comment 23

11 years ago
needs mlk key word

Updated

11 years ago
Keywords: mlk
(Reporter)

Comment 24

11 years ago
what about those lost clipboardcache files? does any of these patches solve this problem too?

ps: see bug 318069, bug 243185
commit leak patch to trunk and both patches into both branches
Status: ASSIGNED → RESOLVED
Last Resolved: 11 years ago
Keywords: fixed1.8.0.3, fixed1.8.1
Resolution: --- → FIXED
Thanks Wolfgang. It's a holiday over here.

Marcin: This does not affect the files. Please file a separate bug about that.
(Reporter)

Comment 27

11 years ago
(In reply to comment #26)
> Marcin: This does not affect the files. Please file a separate bug about that.

ok, see bug 335545
(In reply to comment #14)
> Created an attachment (id=218749) [edit]
> fix leak

roc, et al, was leak fix linux-only?
*** Bug 243185 has been marked as a duplicate of this bug. ***
You need to log in before you can comment on or make changes to this bug.