Closed
Bug 289897
Opened 19 years ago
Closed 18 years ago
huge memory leak when klipper is running
Categories
(Core :: Widget: Gtk, defect)
Tracking
()
RESOLVED
FIXED
People
(Reporter: joi, Assigned: roc)
References
Details
(4 keywords)
Attachments
(2 files, 2 obsolete files)
2.43 KB,
patch
|
darin.moz
:
review+
darin.moz
:
superreview+
darin.moz
:
approval-branch-1.8.1+
dveditz
:
approval1.8.0.4+
|
Details | Diff | Splinter Review |
1.22 KB,
patch
|
darin.moz
:
review+
darin.moz
:
superreview+
dveditz
:
approval-branch-1.8.1+
dveditz
:
approval1.8.0.4+
|
Details | Diff | Splinter Review |
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•19 years ago
|
||
i forgot to mention that konqueror and opera does not have this bug
Reporter | ||
Comment 2•19 years ago
|
||
might be related to Bug 269727
Reporter | ||
Updated•19 years ago
|
Summary: memory leak when klipper is running → huge memory leak when klipper is running
is your gecko based on gtk1 or gtk2?
Assignee: selection → blizzard
Component: Selection → Widget: Gtk
QA Contact: gtk
Reporter | ||
Comment 4•19 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•19 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•19 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•19 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•18 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•18 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•18 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?
Comment 11•18 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).
Assignee | ||
Comment 12•18 years ago
|
||
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?
Assignee | ||
Comment 13•18 years ago
|
||
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?
Assignee | ||
Comment 14•18 years ago
|
||
Attachment #218749 -
Flags: review?
Assignee | ||
Comment 15•18 years ago
|
||
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)
Assignee | ||
Updated•18 years ago
|
Attachment #218748 -
Flags: approval1.8.0.3?
Attachment #218748 -
Flags: approval-branch-1.8.1?(shaver)
Comment 16•18 years ago
|
||
roc: both patches are the same
Assignee | ||
Comment 17•18 years ago
|
||
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•18 years ago
|
Attachment #218753 -
Flags: superreview?(darin)
Attachment #218753 -
Flags: superreview+
Attachment #218753 -
Flags: review?(darin)
Attachment #218753 -
Flags: review+
Assignee | ||
Comment 18•18 years ago
|
||
Checked the permissions patch into trunk.
Comment 19•18 years ago
|
||
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 20•18 years ago
|
||
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•18 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+
Updated•18 years ago
|
Flags: blocking1.8.0.3? → blocking1.8.0.3+
Comment 22•18 years ago
|
||
*** Bug 334823 has been marked as a duplicate of this bug. ***
Comment 23•18 years ago
|
||
needs mlk key word
Reporter | ||
Comment 24•18 years ago
|
||
what about those lost clipboardcache files? does any of these patches solve this problem too? ps: see bug 318069, bug 243185
Comment 25•18 years ago
|
||
commit leak patch to trunk and both patches into both branches
Status: ASSIGNED → RESOLVED
Closed: 18 years ago
Keywords: fixed1.8.0.3,
fixed1.8.1
Resolution: --- → FIXED
Assignee | ||
Comment 26•18 years ago
|
||
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•18 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
Comment 28•18 years ago
|
||
(In reply to comment #14) > Created an attachment (id=218749) [edit] > fix leak roc, et al, was leak fix linux-only?
Comment 29•18 years ago
|
||
*** 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.
Description
•