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

Status: RESOLVED INVALID

(SeaMonkey :: UI Design, defect)

Description

[Oscar van Vliet]

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).

Comment 1

[Oscar van Vliet]

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.

Comment 2

[Oscar van Vliet]

fixing summary

Comment 3

[Oscar van Vliet]

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.

Comment 4

[José Jeria]

So, this is branch only? not trunk?

Comment 5

[Oscar van Vliet]

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

Comment 6

[Oscar van Vliet]

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.

Comment 7

[Serge Gautherie (:sgautherie)]

(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.