Closed Bug 99180 Opened 18 years ago Closed 18 years ago

Memory leak of 64 bytes from 1 block allocated in nsMsgProgressConstructor

Categories

(MailNews Core :: Composition, defect, P1)

x86
Windows 2000
defect

Tracking

(Not tracked)

VERIFIED FIXED
mozilla0.9.7

People

(Reporter: stephend, Assigned: dbaron)

References

Details

(Keywords: memory-leak)

Attachments

(2 files)

MLK: Memory leak of 64 bytes from 1 block allocated in nsMsgProgressConstructor
        Distribution of leaked blocks
                64 bytes from 1 block of 64 bytes (0x0ed89dc8) 
        Allocation location
            new(UINT)+0xc        [new.cpp:23 ip=0x002da05c]
            nsMsgProgressConstructor+0x66
[c:\moz_src\mozilla\mailnews\base\build\nsMsgFactory.cpp:126 ip=0x0a4e5ed6]
            nsGenericFactory::CreateInstance(nsISupports *,nsID const&,void *
*)+0x79 [c:\moz_src\mozilla\xpcom\components\nsGenericFactory.cpp:59 ip=0x101107e9]
            nsComponentManagerImpl::CreateInstance(nsID const&,nsISupports
*,nsID const&,void * *)+0x13c
[c:\moz_src\mozilla\xpcom\components\nsComponentManager.cpp:1544 ip=0x1011ce2c]
            nsComponentManager::CreateInstance(nsID const&,nsISupports *,nsID
const&,void * *)+0xd3
[c:\moz_src\mozilla\xpcom\components\nsComponentManager.cpp:3072 ip=0x10125b53]
            nsJSCID::CreateInstance(nsISupports * *)+0x8d2
[c:\moz_src\mozilla\js\src\xpconnect\src\xpcjsid.cpp:803 ip=0x049a027c]
            XPTC_InvokeByIndex+0x78
[c:\moz_src\mozilla\xpcom\reflect\xptcall\src\md\win32\xptcinvoke.cpp:137
ip=0x10163bc8]
           
XPCWrappedNative::CallMethod(XPCCallContext&,CallMode::XPCWrappedNative)+0x2011
[c:\moz_src\mozilla\js\src\xpconnect\src\xpcwrappednative.cpp:1952 ip=0x049d2471]
            XPC_WN_CallMethod(JSContext *,JSObject *,UINT,long *,long *)+0x3be
[c:\moz_src\mozilla\js\src\xpconnect\src\xpcwrappednativejsops.cpp:1254
ip=0x049ea64e]
            js_Invoke+0x1f8b     [c:\moz_src\mozilla\js\src\jsinterp.c:807
ip=0x0448ba7b]
leak bugs / qacontact --> me.
QA Contact: sheelar → stephend
Leaking 64 bytes for each progress meter sounds a bit steep, am I right?
it's not that awful - there would only be one of those per thread pane window.
However there would also be one of those per msg send progress window, so that
would be 64 bytes per message send. 
To reproduce:

1. mozilla.exe -compose
2. To: stephend@netscape.com (let it autocomplete the 'd@netscape.com' from 
local address book)
3. Tab to the subject
4. Tab to the body
5. Hit Send
6. Hit Enter.
nsbeta1+, unless we can determine it's an isolated leak.
Keywords: nsbeta1+
I just ran into a leak that causes an nsMsgProgress (and a bunch of stuff it
holds on to, although that would be rooted through JS so you wouldn't see it in
purify except as a shutdown leak) to be leaked on sending an email message. 
I'll attach the fix.  (I did a little string cleanup a few lines below the fix,
too, since I hate |AssignWithConversion| and it's probably going away at some
point anyway.)  There was also some wacky use-the-wrong-IID stuff going on (but
it was OK since nsIMsgProgress inherits from nsIWebProgress), but I replaced it
with a cast since  a QI on |this| can safely be replaced by a static_cast if
that cast compiles.
Actually, I'm not sure how that QI managed to work, since it was a QI for
nsIMsgStatusFeedback, unless the user of the pointer on the other end just did a
QI again for the interface they wanted rather than using what was provided.
Comment on attachment 58944 [details] [diff] [review]
leak fix

r/sr=bienvenu, whichever one you need.
Attachment #58944 - Flags: superreview+
Taking, so I remember to check it in.
Assignee: ducarroz → dbaron
Priority: -- → P1
Target Milestone: --- → mozilla0.9.7
Status: NEW → ASSIGNED
Comment on attachment 58944 [details] [diff] [review]
leak fix

r=waterson
Attachment #58944 - Flags: review+
Fix checked in 2001-11-27 20:47 PDT.
Status: ASSIGNED → RESOLVED
Closed: 18 years ago
Resolution: --- → FIXED
Verified FIXED using Purify on Windows 2000 with the latest trunk build.
Status: RESOLVED → VERIFIED
Product: MailNews → Core
Product: Core → MailNews Core
You need to log in before you can comment on or make changes to this bug.