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)

x86
Linux
defect
Not set
normal

Tracking

(Not tracked)

RESOLVED WONTFIX

People

(Reporter: skk, Assigned: wtc)

References

()

Details

Attachments

(1 file, 1 obsolete file)

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.
Attached file OpenBSD allocator patch for mozilla (obsolete) —
Assignee: nobody → wtchang
Component: Tabbed Browser → NSPR
Product: Firefox → NSPR
QA Contact: tabbed.browser → nspr
Version: unspecified → other
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
see also bug 130157
Andrew, could you reassign this bug to the right product:component? Thanks.
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.
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
This was obsoleted in the meantime by the switch to jemalloc, right? Not sure how to mark this bug, though.
Will somebody please close this?
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.

Attachment

General

Created:
Updated:
Size: