Closed Bug 13289 Opened 21 years ago Closed 21 years ago
MLK: char* leaked in ns
Profile::Get Profile Dir()
This is really in the backend in nsProfile.cpp In nsProfile::GetProfileDir(), it does this: orgProfileDir = PL_strdup(profileDir->GetCString()); (speaking of which, this should be using nsCRT::strdup() instead of PL_strdup().) It never frees up that memory though. It is only used to pass to the constructor of the nsFileSpec tmpFileSpec. This ends up happening a good number of times. [W] MLK: Memory leak of 34 bytes from 1 block allocated in PL_strdup Distribution of leaked blocks 34 bytes from 1 block of 34 bytes (0x0980e908) allocation number 208960 Allocation location malloc [dbgheap.c:129] PL_strdup [strdup.c:30] nsProfile::GetProfileDir(char const*,nsFileSpec *) [nsProfile.cpp:359] nsProfile::GetCurrentProfileDir(nsFileSpec *) [nsProfile.cpp:822] nsBookmarksService::GetBookmarksFile(nsFileSpec *) [nsBookmarksService.cpp:2976] nsBookmarksService::WriteBookmarks(nsIRDFDataSource *,nsIRDFResource *) [nsBookmarksService.cpp:3220] nsBookmarksService::Flush(void) [nsBookmarksService.cpp:2954] nsBookmarksService::UpdateBookmarkLastVisitedDate(char const*) [nsBookmarksService.cpp:2242] XPTC_InvokeByIndex [xptcinvoke.cpp:133] nsXPCWrappedNativeClass::CallWrappedMethod(JSContext *,nsXPCWrappedNative *,XPCNativeMemberDescriptor const*,CallMode::nsXPCWrappedNativeClass,UINT,long *,long *) [xpcwrappednativeclass.cpp:507] WrappedNative_CallMethod(JSContext *,JSObject *,UINT,long *,long *) [xpcwrappednativejsops.cpp:170] js_Invoke [jsinterp.c:654] js_Interpret [jsinterp.c:2228] js_Invoke [jsinterp.c:670] js_InternalCall [jsinterp.c:747]
Cc'ing more appropriate people I think (hopefully!)
Summary: char* leaked in nsProfile::GetProfileDir() → MLK: char* leaked in nsProfile::GetProfileDir()
Actually, I'm pretty sure you even need to strdup at all, because the nsFileSpec constructor will copy for you. You might even be able to use nsAutoString autoOrgProfileDir(orgProfileDir); nsFileSpec tmpFileSpec(autoOrgProfileDir); because you ensure that profileDir's lifetime exceeds that of the tmpFileSpec.
I just fixed this. Gotta love those nsXPIDLStrings.
Status: NEW → RESOLVED
Closed: 21 years ago
Resolution: --- → FIXED
What does ``dev bug'' mean? Have we actually verified that this is fixed, by checking subsequent purify runs or something?
'dev bug' comment suggested for use by QA when bug is code fix by developer that has no test case. I check lxr to see if code checked in by engineer who said he did it
Well, there's no test case attached, but we can surely determine if the fix is proper by using the same tools that found the MLK in the first place. What's the difference between RESOLVED/FIXED and VERIFIED/FIXED if there's no actual verification? (I'm sure someone would be happy to help you set up purify if you want to verify this sort of bug.)
reassigning QA contact to bruce, reopening.
Status: REOPENED → RESOLVED
Closed: 21 years ago → 21 years ago
QA Contact: gbush → bruce
Moving all Profile Manager bugs to new Profile Manager Backend component. Profile Manager component to be deleted.
You need to log in before you can comment on or make changes to this bug.