Closed Bug 258240 Opened 20 years ago Closed 16 years ago

On closing tab with QT or JEP plugin content, threads (and memory) are not released

Categories

(SeaMonkey :: UI Design, defect)

1.7 Branch
PowerPC
macOS
defect
Not set
normal

Tracking

(Not tracked)

RESOLVED INVALID

People

(Reporter: ovvldc, Unassigned)

References

()

Details

(Keywords: memory-leak, top100)

User-Agent:       Mozilla/5.0 (Macintosh; U; PPC Mac OS X Mach-O; nl-NL; rv:1.7.2) Gecko/20040803
Build Identifier: Mozilla/5.0 (Macintosh; U; PPC Mac OS X Mach-O; nl-NL; rv:1.7.2) Gecko/20040803

If a page is openend in a tab, containing content or the Java Embedding Plugin
0.83 (see http://sourceforge.net/projects/javaplugin/) or Quicktime 6.5.1 and
the tab is subsequently closed, the activity monitor shows fewer threads are
released than were made to accomodate the page (usually 2 to 4 net gain). 

It also seems not to release some memory (my Mozilla build is now using a
whopping 90MB of physical RAM and 450 MB of virtual memory, after surfing for
about an hour or two).

This problem does not occurr with flash pages.

Reproducible: Always
Steps to Reproduce:
1. Ensure Quicktime and JEP are installed.
2. Visit a site with QT or Java content, like www.apple.com/quicktime/trailers
3. Close the tab
4. Compare threads and memory before and after in the activity monitor
Actual Results:  
After several tries, memory consumption is *way* up and thread count for mozilla
is increased

Expected Results:  
Released all of the threads and memory.

Doesn't seem to happen with the most recent Flash (7.0.24).
Might be related to bug 256822 (JS window objects leaked when opening / closing
windows). I couldn't tell from the description.

The memory consumption really slows down switching to another app and switching
back. I don't recall having this problem using 1.6 but I could be wrong.
Keywords: footprint, mlk, perf, top100
Version: Trunk → 1.7 Branch
fixing summary
Summary: On closing tab with QT and JEP plugin, threads and memory are not released → On closing tab with QT or JEP plugin content, threads (and memory) are not released
Changing component, per the discussion in bug 131456.

Apparently this will be hard to track down. In any case, I recently had Mozilla
up to using 1.16 GB of VM. Just a little too much for my taste. Adding the
dataloss keywords because enough VM can lead to an empty disk which can make it
impossible to save data from any app.
Component: Plug-ins → XP Apps
Keywords: dataloss
Product: Core → Mozilla Application Suite
So, this is branch only? not trunk?
No idea, haven't tried the new Alpha build on account of constant comments they
are buggy. Also, some fixes are waiting to be ported, AFAIK. Will try with 1.8alpha6
Steven Michaud has recently fixed some memory leaks in his plugin, so this bug
should be somewhat less urgent. Still, leaks remain, as is obvious from the
ongoing discussion in bug 131456 (which already has 181 votes by now)..

At this point I am wondering if this bug is caused by a combination of Mozilla
leaks, QT leaks, JVM leaks and other plugin leaks. If so, tracing will be an
iterative process.
(4.5 years later)

No (more) reply from reporter.

MozillaAS v1.7.x is not supported anymore.

(Would have been "Incomplete", now is) R.Invalid.

Reopen if you can reproduce with SeaMonkey v1.1.9.
Status: UNCONFIRMED → RESOLVED
Closed: 16 years ago
Keywords: dataloss, footprint, perf
Resolution: --- → INVALID
You need to log in before you can comment on or make changes to this bug.