Closed Bug 99180 Opened 20 years ago Closed 20 years ago
Memory leak of 64 bytes from 1 block allocated in ns
Msg Progress Constructor
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]
20 years ago
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: firstname.lastname@example.org (let it autocomplete the 'email@example.com' from local address book) 3. Tab to the subject 4. Tab to the body 5. Hit Send 6. Hit Enter.
20 years ago
nsbeta1+, unless we can determine it's an isolated leak.
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
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: 20 years ago
Resolution: --- → FIXED
Verified FIXED using Purify on Windows 2000 with the latest trunk build.
Status: RESOLVED → VERIFIED
You need to log in before you can comment on or make changes to this bug.