In <msgHdrViewSMIMEOverlay.js>, |var smimeHeaderSink| leaks each time a 3-Pane MailNews window is closed, as reported by Leak Detector Extension

RESOLVED DUPLICATE of bug 365723

Status

MailNews Core
Security
--
major
RESOLVED DUPLICATE of bug 365723
12 years ago
10 years ago

People

(Reporter: Philip Chee, Assigned: sgautherie)

Tracking

({memory-leak})

Trunk
memory-leak

Firefox Tracking Flags

(Not tracked)

Details

(URL)

Attachments

(1 attachment, 2 obsolete attachments)

(Reporter)

Description

12 years ago
Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9a1) Gecko/20060526
SeaMonkey/1.5a

1. Install the Leak Detector Extension on SeaMonkey trunk.
2. Restart SeaMonkey with -mail
3. Open a new window.
4. Close the original mailnews window.
5. Leak Detector window opens with the following report:

[+] [leaked object] (1855e10) = [object Object]
 [+] maxWantedNesting (1855e18, chrome://messenger-smime/content/msgHdrViewSMIMEOverlay.js, 56-57) = function () {
    return 1;
}
  [ ] prototype (9c1948) = [object Object]
 [+] signedStatus (1855e20, chrome://messenger-smime/content/msgHdrViewSMIMEOverlay.js, 61-94) = function (aNestingLevel, aSignatureStatus, aSignerCert) {
    if (aNestingLevel > 1) {
        return;
    }
    gSignatureStatus = aSignatureStatus;
    gSignerCert = aSignerCert;
    gSMIMEContainer.collapsed = false;
    gSignedUINode.collapsed = false;
    gSignedStatusPanel.collapsed = false;
    switch (aSignatureStatus) {
      case nsICMSMessageErrors.SUCCESS:
        gSignedUINode.setAttribute("signed", "ok");
        gStatusBar.setAttribute("signed", "ok");
        break;
      case nsICMSMessageErrors.VERIFY_NOT_YET_ATTEMPTED:
        gSignedUINode.setAttribute("signed", "unknown");
        gStatusBar.setAttribute("signed", "unknown");
        break;
      case nsICMSMessageErrors.VERIFY_CERT_WITHOUT_ADDRESS:
      case nsICMSMessageErrors.VERIFY_HEADER_MISMATCH:
        gSignedUINode.setAttribute("signed", "mismatch");
        gStatusBar.setAttribute("signed", "mismatch");
        break;
      default:
        gSignedUINode.setAttribute("signed", "notok");
        gStatusBar.setAttribute("signed", "notok");
        break;
    }
}
  [ ] prototype (9c1980) = [object Object]
 [+] encryptionStatus (1855e28, chrome://messenger-smime/content/msgHdrViewSMIMEOverlay.js, 99-126) = function (aNestingLevel, aEncryptionStatus, aRecipientCert) {
    if (aNestingLevel > 1) {
        return;
    }
    gEncryptionStatus = aEncryptionStatus;
    gEncryptionCert = aRecipientCert;
    gSMIMEContainer.collapsed = false;
    gEncryptedUINode.collapsed = false;
    gEncryptedStatusPanel.collapsed = false;
    if (nsICMSMessageErrors.SUCCESS == aEncryptionStatus) {
        gEncryptedUINode.setAttribute("encrypted", "ok");
        gStatusBar.setAttribute("encrypted", "ok");
    } else {
        gEncryptedUINode.setAttribute("encrypted", "notok");
        gStatusBar.setAttribute("encrypted", "notok");
    }
    if (gEncryptedURIService) {
        gMyLastEncryptedURI = GetLoadedMessage();
        gEncryptedURIService.rememberEncrypted(gMyLastEncryptedURI);
    }
}
  [ ] prototype (9c19e0) = [object Object]
 [+] QueryInterface (1855e30, chrome://messenger-smime/content/msgHdrViewSMIMEOverlay.js, 131-134) = function (iid) {
    if (iid.equals(Components.interfaces.nsIMsgSMIMEHeaderSink) ||
        iid.equals(Components.interfaces.nsISupports)) {
        return this;
    }
    throw Components.results.NS_NOINTERFACE;
}
(Reporter)

Comment 1

12 years ago
<http://lxr.mozilla.org/seamonkey/source/mail/extensions/smime/content/msgHdrViewSMIMEOverlay.js>

cc mscott for the Thunderbird version of msgHdrViewSMIMEOverlay.js
See bug #336973 and bug #339072 + add "mlk" keyword.
(Reporter)

Updated

12 years ago
Blocks: 339072
(Assignee)

Updated

12 years ago
Blocks: 336973
(Assignee)

Comment 3

12 years ago
These 3 bugs are clearly "duplicates".
Since Philip (and I and Neil) started a thread in <news://news.mozilla.org:119/mozilla.dev.apps.seamonkey> ten days ago,
let's work here ... then we'll see what's left of the other two.
Keywords: mlk
(Assignee)

Comment 4

12 years ago
[Mozilla/5.0 (Windows; U; Win98; en-US; rv:1.8.1a2) Gecko/20060524 SeaMonkey/1.1a] (nightly) (W98SE)

Confirmed (again) with SMv1.1a branch.
Severity: normal → major
Summary: Memory leak in msgHdrViewSMIMEOverlay.js detected by Leak Detector Extension → In <msgHdrViewSMIMEOverlay.js>, |var smimeHeaderSink| leaks each time a 3-Pane MailNews window is closed, as reported by Leak Detector Extension
Target Milestone: --- → seamonkey1.1alpha
(Assignee)

Comment 5

12 years ago
This var is referenced at
{{
173 function msgHdrViewSMIMEOnLoad(event)
174 {
175   // we want to register our security header sink as an opaque nsISupports
176   // on the msgHdrSink used by mail.....
177   msgWindow.msgHeaderSink.securityInfo = smimeHeaderSink;
}}
but is not cleared in the OnUnload function.

I'll test this and submit a patch...
Assignee: general → gautheri
(Assignee)

Comment 6

12 years ago
Created attachment 223564 [details] [diff] [review]
(Av1-SM) <msgHdrViewSMIMEOverlay.js>

[Mozilla/5.0 (Windows; U; Win98; en-US; rv:1.8.1a2) Gecko/20060524 SeaMonkey/1.1a] (nightly) (W98SE)

Unset the sink,
and space nits.
Attachment #223564 - Flags: superreview?(neil)
Attachment #223564 - Flags: review?(neil)
(Assignee)

Updated

12 years ago
Status: NEW → ASSIGNED
Component: General → MailNews: Security
Product: Mozilla Application Suite → Core
Target Milestone: seamonkey1.1alpha → mozilla1.8.1beta1

Comment 7

12 years ago
From an email exchange with dbaron:
>It's possible that this is something that just takes multiple cycles of
>garbage collection to go away. [...] this *could* be a case of a false positive
(Assignee)

Comment 8

12 years ago
(In reply to comment #7)
> From an email exchange with dbaron:
> >It's possible that this is something that just takes multiple cycles of
> >garbage collection to go away. [...] this *could* be a case of a false positive

I fully agree that this one (and the related ones in other bugs) looks like possible false positive.
(Is there any tool that would confirm this, either way ?)

In the doubt, or for example if the "multiple GC cycles" is the exact explanation, would we accept the additional clearing code to gain (silence and) "faster" GC !?
(Or is there any way that the Leak Detector could be improved/setup to force these extra cycles before it reports the leak ?)
This was a false positive, and the report will no longer appear in Leak Monitor 0.3.0.
Status: ASSIGNED → RESOLVED
Last Resolved: 12 years ago
Resolution: --- → INVALID

Updated

12 years ago
Attachment #223564 - Flags: superreview?(neil)
Attachment #223564 - Flags: review?(neil)

Comment 10

12 years ago
(In reply to comment #9)
>This was a false positive, and the report will no longer appear in Leak Monitor 0.3.0.
Verified.
Status: RESOLVED → VERIFIED
(Assignee)

Comment 11

12 years ago
(In reply to comment #10)
> (In reply to comment #9)
> >This was a false positive, and the report will no longer appear in Leak Monitor 0.3.0.
> Verified.

[Mozilla/5.0 (Windows; U; Win98; en-US; rv:1.8.1a3) Gecko/20060603 SeaMonkey/1.1a] (nightly) (W98SE)

It turns out that this statement is a kind of "false positive" too, on MOZILLA_1_8_BRANCH ;-<

While I confirm that L.M. v0.3.0 is not reporting the leaks in the usual case anymore,
I get them again when using offline mode:

Reordered steps, to see only these leaks:
1. Start SeaMonkey with any window but MailNews.
2. Go offline. (<-- new step !)
3. Open a MailNews window.
4. Close it.

In other words, the leaks are still reported (at each window closure), unless I open+close while online (and the POP3+IMAP4 messages checks happen).

Can anyone test/confirm this on Trunk ?
Status: VERIFIED → REOPENED
Resolution: INVALID → ---
(Reporter)

Comment 12

12 years ago
Created attachment 224334 [details]
LeakMon 0.3.0 report on Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9a1) Gecko/20060526 Mnenhy/0.7.4.0 SeaMonkey/1.5a

I get this report when tested off-line on:

Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9a1) Gecko/20060526 Mnenhy/0.7.4.0 SeaMonkey/1.5a
(Assignee)

Comment 13

12 years ago
(In reply to comment #11)
> I get them again when using offline mode:

And the patch still fixes this (new) case.

NB: 'them' meant 'this bug and bug 339072'.

*****

(In reply to comment #12)
> I get this report when tested off-line on:

<msgMail3PaneWindow.js> report confirmed on MOZILLA_1_8_BRANCH:
I'm not sure of the reduced steps yet, but I noticed this when testing before writing comment 11.

(Leave it there for now, but filing a separate bug would be appropriate when the time comes.)

Do you still get the two already reported bugs (without the patches) ?
(Reporter)

Comment 14

12 years ago
Sorry for the confusion. I can confirm the memory leak in msgHdrViewSMIMEOverlay.js on:

Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9a1) Gecko/20060602 Mnenhy/0.7.4.0 SeaMonkey/1.5a

Using the following steps:

1. Start SeaMonkey (navigator window).
2. Go off-line if not already off-line.
3. Open a mail-news window (Window->Mail&Newsgroups)
4. Make sure that you are using the classic layout and the message (F8) pane is open.
5. Click on a mail folder in the folder pane.
6. Click on a message row in the list of messages (not sure what's its called) pane.
7. Close mail-news window.

This leak DOES NOT occur of the message pane (F8) is NOT open.

Comment 15

12 years ago
Comment on attachment 224334 [details]
LeakMon 0.3.0 report on Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9a1) Gecko/20060526 Mnenhy/0.7.4.0 SeaMonkey/1.5a

Except that either you accidentally didn't paste the right report or it's not relevant because it only mentions msgMail3PaneWindow.js ...

Comment 16

12 years ago
(In reply to comment #15)
OK, so it helps if I read all my bugmail first ;-)

This bug is still invalid, because the leak from msgHdrViewOverlay.js causes this leak as a side-effect (via the securityInfo property).
Status: REOPENED → RESOLVED
Last Resolved: 12 years ago12 years ago
Resolution: --- → INVALID
(Reporter)

Comment 17

12 years ago
Created attachment 224351 [details]
LeakMon 0.3.0 report on Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9a1) Gecko/20060602 Mnenhy/0.7.4.0 SeaMonkey/1.5a

Sigh. Here is the right one (I hope)
Attachment #224334 - Attachment is obsolete: true
Leak Monitor 0.3.1 may fix additional false positives.  However, more importantly, it will alert (Reclaimed Leak Alert) if any of the memory it previously reported as leaked has been reclaimed.  So if you don't see the Reclaimed Leak Alert almost immediately, then it's probably a real problem.  (Note that you may see the Reclaimed Leak Alert print to stdout during shutdown; it prints to the console instead of alerting during the quit process.  If this happens, then it's definitely a real leak -- and one of the harder types to track down, since it's not actually still present at shutdown.)
(Assignee)

Comment 19

10 years ago
Eventually, it turned out to be:
R.Duplicate, per bug 339072 comment 20.
No longer blocks: 339072
Resolution: INVALID → DUPLICATE
Target Milestone: mozilla1.8.1beta1 → ---
Duplicate of bug: 365723
(Assignee)

Updated

10 years ago
Attachment #223564 - Attachment is obsolete: true
QA Contact: general → security
(Assignee)

Updated

10 years ago
No longer blocks: 336973
Product: Core → MailNews Core
You need to log in before you can comment on or make changes to this bug.