Closed
Bug 366937
Opened 19 years ago
Closed 14 years ago
Firefox doesn't release memory upon closing tabs, and use OpenBSD allocator for fix it
Categories
(NSPR :: NSPR, defect)
Tracking
(Not tracked)
RESOLVED
WONTFIX
4.8.9
People
(Reporter: skk, Assigned: wtc)
References
()
Details
Attachments
(1 file, 1 obsolete file)
45.69 KB,
patch
|
Details | Diff | Splinter Review |
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.8.1.1) Gecko/20061208 Firefox/2.0.0.1
Build Identifier: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.8.1.1) Gecko/20061208 Firefox/2.0.0.1
Sorry for my english..
When I open firefox a blank page, he use a memory (VSZ and RSS memory accordingly, watched from ps):
103060 23540 (kb)
Open ~100 tabs (text and images) and he use:
143028 61900
After close all tabs:
141200 60832
Memory doesn't release to OS.
I read this russian page:http://mr.himki.net/index-alloc.html and use OpenBSD allocator:http://mr.himki.net/OpenBSD_malloc_Linux.c, compile it: gcc -shared -fPIC -O2 OpenBSD_malloc_Linux.c -o malloc.so
and start Firefox: LD_PRELOAD=/path/to/malloc.so firefox
Firefox use:
105256 25536
open ~100 text and images pages:
145976 63156
and close all tabs:
126100 46116
Firefox release memory, but not all.
http://polar.ihep.su:8002/mozilla_malloc_linux-patch.gz - this is a patch for mozilla-based programs source
Reproducible: Always
Steps to Reproduce:
1.open firefox
2.open some tabs
3.close all tabs
firefox doesn't return memory
Actual Results:
I tested Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.8.1.1) Gecko/20061208 Firefox/2.0.0.1 and Windows version Firefox 2.0. In Windows version this bug doesn't work, memory release.
Reporter | ||
Comment 1•19 years ago
|
||
Updated•19 years ago
|
Assignee: nobody → wtchang
Component: Tabbed Browser → NSPR
Product: Firefox → NSPR
QA Contact: tabbed.browser → nspr
Version: unspecified → other
Comment 2•19 years ago
|
||
Comment on attachment 251411 [details]
OpenBSD allocator patch for mozilla
bugzilla "patches" have to be text/plain
Attachment #251411 -
Attachment is patch: false
Attachment #251411 -
Attachment mime type: text/plain → application/x-gzip
Comment 3•19 years ago
|
||
see also bug 130157
Assignee | ||
Comment 4•19 years ago
|
||
Andrew, could you reassign this bug to the right product:component? Thanks.
Comment 5•19 years ago
|
||
wtc, the attached patch only touches prmem.c, so this is the right product:component (unless the problem shouldn't be fixed in prmem.c). bug 130157 is in a different component, but it contains only discussion of the problem.
Assignee | ||
Comment 6•19 years ago
|
||
NSPR used this allocator before. Its source code is in
mozilla/nsprpub/pr/src/malloc/prmalloc.c. You can find it
by searching for "BEER" in the NSPR source tree:
http://lxr.mozilla.org/nspr/search?string=BEER
The reason NSPR used this allocator was to have a version
of malloc and free that was safe with respect to NSPR's own
user-level threads. Now all the major Unix platforms have
native threads, so it's no longer necessary to override
malloc and free for thread safety.
The decision to override malloc and free for better performance
or more efficient use of memory should be left to the application.
Attachment #251411 -
Attachment is obsolete: true
Comment 7•17 years ago
|
||
This was obsoleted in the meantime by the switch to jemalloc, right? Not sure how to mark this bug, though.
Comment 8•14 years ago
|
||
Will somebody please close this?
Assignee | ||
Comment 9•14 years ago
|
||
Marked the bug WONTFIX.
Status: UNCONFIRMED → RESOLVED
Closed: 14 years ago
Resolution: --- → WONTFIX
Target Milestone: --- → 4.8.9
You need to log in
before you can comment on or make changes to this bug.
Description
•