Closed Bug 103084 Opened 24 years ago Closed 24 years ago

Memory leak of 8 bytes from 1 block allocated in nsLDAPURL::Init

Categories

(MailNews Core :: LDAP Integration, defect, P3)

x86
Windows 2000
defect

Tracking

(Not tracked)

VERIFIED FIXED
mozilla1.0

People

(Reporter: stephend, Assigned: leif)

Details

(Keywords: memory-leak)

Attachments

(1 file)

Small, small leak. Trunk CVS pull, 8 pm 10-3-2001, Windows 2000. Using the autocomplete setup provided by hong@netscape.com. dmose had asked a long time ago if I could run this, sorry it took so long. Steps to Reproduce: 1. Mozilla.exe -compose. 2. Type dmos (it'll complete to Dan Mosedale <dmose@netscape.com>). 3. Tab to subject. 4. Exit. [W] MLK: Memory leak of 8 bytes from 1 block allocated in nsLDAPURL::Init (void) Distribution of leaked blocks Allocation location new(UINT)+0xc [C:\WINNT\SYSTEM32\msvcrt.DLL ip=0x580039cb] nsLDAPURL::Init(void)+0x3f [c:\moz_src\mozilla\directory\xpcom\base\src\nsLDAPURL.cpp:66 ip=0x0df41c34] nsLDAPURL::Init() { if (!mAttributes) { => mAttributes = new nsCStringArray(); if (!mAttributes) { NS_ERROR("nsLDAPURL::Init: out of memory "); return NS_ERROR_OUT_OF_MEMORY; nsLDAPURLConstructor+0xe8 [c:\moz_src\mozilla\directory\xpcom\base\src\nsLDAPProtocolModule.cpp:55 ip=0x0df43f80] NS_GENERIC_FACTORY_CONSTRUCTOR(nsLDAPOperation); NS_GENERIC_FACTORY_CONSTRUCTOR(nsLDAPMessage); NS_GENERIC_FACTORY_CONSTRUCTOR(nsLDAPServer); => NS_GENERIC_FACTORY_CONSTRUCTOR_INIT(nsLDAPURL, Init); NS_GENERIC_FACTORY_CONSTRUCTOR_INIT(nsLDAPService, Init); #ifdef MOZ_LDAP_XPCOM_EXPERIMENTAL nsGenericFactory::CreateInstance(nsISupports *,nsID const&,void * *) +0x50 [c:\moz_src\mozilla\xpcom\components\nsGenericFactory.cpp:74 ip=0x100a7260] REFNSIID aIID, void **aResult) { if (mInfo->mConstructor) { => return mInfo->mConstructor(aOuter, aIID, aResult); } return NS_ERROR_FACTORY_NOT_REGISTERED; nsJSCID::CreateInstance(nsISupports * *)+0x4b0 [c:\moz_src\mozilla\js\src\xpconnect\src\xpcjsid.cpp:803 ip=0x047127d2] nsresult rv; rv = nsComponentManager::CreateInstance(*mDetails.GetID(), nsnull, iid, => (void**) getter_AddRefs (inst)); NS_ASSERTION(NS_FAILED(rv) || inst, "component manager returned success, but instance is null!"); if(NS_FAILED(rv) || !inst) XPTC_InvokeByIndex+0x75 [c:\moz_src\mozilla\xpcom\reflect\xptcall\src\md\win32\xptcinvoke.cpp:152 ip=0x100d4c0e] mov eax,methodIndex shl eax,2 // *= 4 add edx,eax => call [edx] // stdcall, i.e. callee cleans up stack. } } #pragma warning(default : 4035) // restore default XPCWrappedNative::CallMethod(XPCCallContext&,CallMode::XPCWrappedNative) +0x10a8 [c:\moz_src\mozilla\js\src\xpconnect\src\xpcwrappednative.cpp:1951 ip=0x0472a995] // do the invoke invokeResult = XPTC_InvokeByIndex(callee, vtblIndex, => paramCount, dispatchParams); // resume non-blocking JS operations now } XPC_WN_CallMethod(JSContext *,JSObject *,UINT,long *,long *)+0x17b [c:\moz_src\mozilla\js\src\xpconnect\src\xpcwrappednativejsops.cpp:1254 ip=0x0473503e] if(!XPCNativeMember::GetCallInfo(ccx, funobj, &iface, &member)) return Throw(NS_ERROR_XPC_CANT_GET_METHOD_INFO, cx); ccx.SetCallInfo(iface, member, JS_FALSE); => return XPCWrappedNative::CallMethod(ccx); } JSBool JS_DLL_CALLBACK js_Invoke+0xba4 [c:\moz_src\mozilla\js\src\jsinterp.c:809 ip=0x04428a0f] /* If native, use caller varobj and scopeChain for eval. */ frame.varobj = fp->varobj; frame.scopeChain = fp->scopeChain; => ok = native(cx, frame.thisp, argc, frame.argv, &frame.rval); JS_RUNTIME_METER(cx->runtime, nativeCalls); } else if (script) { /* Use parent scope so js_GetCallObject can find the right "Call". */ js_Interpret+0xb27f [c:\moz_src\mozilla\js\src\jsinterp.c:2732 ip=0x04434fb3] goto out; } => ok = js_Invoke(cx, argc, 0); RESTORE_SP(fp); if (!ok) goto out;
Giving to Leif.
Assignee: dmose → leif
Attached patch Memory leak fixSplinter Review
Priority: -- → P3
Target Milestone: --- → mozilla1.0
Status: NEW → ASSIGNED
Mitesh - Can you review this please?
Comment on attachment 53649 [details] [diff] [review] Memory leak fix looks good. r=mitesh
Attachment #53649 - Flags: review+
this should just be delete mAttributes; the check for null is redundant, if not downright wasteful :-) the delete operator will check for null. Other than that, sr=bienvenu. I'll go edit the attachment to note my sr.
Comment on attachment 53649 [details] [diff] [review] Memory leak fix sr=bienvenu, if you take out the null check.
Attachment #53649 - Flags: superreview+
Keywords: nsbeta1
Thanks David, I learn something new every day :). -- Leif
QA-->Myself. I'm set up to verify this using Purify.
QA Contact: yulian → stephend
Checked in on trunk.
Status: ASSIGNED → RESOLVED
Closed: 24 years ago
Resolution: --- → FIXED
Verified FIXED. I've filed 2 bugs, bug 106857 and bug 106858 for new leaks.
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.

Attachment

General

Creator:
Created:
Updated:
Size: