User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.8b2) Gecko/20050409 Firefox/1.0+ Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.8b2) Gecko/20050409 Firefox/1.0+ in mozilla\nsprpub\pr\src\linking\prlink.c, function pr_LoadLibraryByPathname. Line 955: h = LoadLibrary(name); this is never freed with FreeLibrary. Recommendation: Add a function, nsDLL::UnLoad(PRLibrary* pLib), or nsLocalFile::Unload(PRLibrary* pLib), or something similar, I don't realy know. this funciton should include the line: FreeLibrary(pLib); Reproducible: Always Steps to Reproduce: Detected with BoundsChecker 7.2.0
NSPR provides a function to free a library, PR_FreeLibrary . The problem is mostly that the application isn't using this function. You didn't post the application stack where the call to PR_LoadLibrary was made. You need to examine it, and reassign this bug to the correct component that contains that call.
NSPR stores 'h' in the 'dlh' member of a PRLibrary structure and returns a pointer to the PRLibrary structure to the caller. The caller needs to call PR_UnloadLibrary when it is done with the PRLibrary structure. On Windows, PR_UnloadLibrary calls FreeLibrary on the 'dlh' member of PRLibrary.
Status: UNCONFIRMED → RESOLVED
Last Resolved: 13 years ago
Resolution: --- → INVALID
OK..sorry for all my mistakes here. I'm new :\ nsDll::Load(void) (in line 237 mozilla\xpcom\components\xcDll.cpp), which calls nsLocalFile::Load(PRLibrary * *_retval) (mozilla\xpcom\io\nsLocalFileWin.cpp), Which calls PR_LoadLibrary (prlink.c) (and then PR_LoadLibraryWithFlags and then pr_LoadLibraryByPathname)
Status: RESOLVED → UNCONFIRMED
Resolution: INVALID → ---
This bug needs to be resolved invalid or be changed to the product that you ran BoundsChecker on.
I ran BoundsChecker on FireFox (Gecko Browser) Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.8b2) Gecko/20050411 Firefox/1.0+ --enable-debug. that doesn't matter. The fact is, that the function nsDll::Load(void) Loads a library and never frees it. BoundsChecker wouldn't say this without reason. It detected that the library was never released.
Changed product to Firefox. This may belong in the Core product depending on what we find out. The application needs to call nsDll::Unload(void) to unload the library. nsDll::Unload(void) calls PR_UnloadLibrary, which in turn calls FreeLibrary on Windows. To investigate this bug we need all the relevant information reported by BoundsChecker. In particular, a stack trace that shows who calls nsDll::Load(void). This will help us identify what library is loaded and why nsDll::Unload(void) isn't called.
Assignee: wtchang → firefox
Component: NSPR → General
Product: NSPR → Firefox
QA Contact: wtchang → general
Version: other → Trunk
OK. now I set BoundsChecker to write 10 functions in the Allocation Call Stack, and I have the information. mozilla\xpcom\components\nsComponentManager.cpp line 3194, nsComponentManagerImpl::AutoRegisterImpl calls nsNativeComponentLoader::AutoRegisterComponents nsNativeComponentLoader::AutoRegisterComponents (mozilla\xpcom\components\nsNativeComponentLoader.cpp, line 184) calls nsNativeComponentLoader::RegisterComponentsInDir nsNativeComponentLoader::RegisterComponentsInDir (mozilla\xpcom\components\nsNativeComponentLoader.cpp, line 244) calls nsNativeComponentLoader::AutoRegisterComponent nsNativeComponentLoader::AutoRegisterComponent (same file, line 886) calls nsNativeComponentLoader::SelfRegisterDll ===> nsNativeComponentLoader::SelfRegisterDll calls nsDll::Load(void) (same file, line 386) HTH
Changed product/component to Core:XPCOM for investigation.
Assignee: firefox → dougt
Component: General → XPCOM
Product: Firefox → Core
QA Contact: general
We load XPCOM components for the duration of their usage, and do not unload them by design. There are also some old bugs to unload XPCOM components on shutdown, and we might be able to do that in the 1.9 cycle but it is very tricky.
Status: UNCONFIRMED → RESOLVED
Last Resolved: 13 years ago → 13 years ago
Resolution: --- → INVALID
Now I've got something completely different, and I have a gut feeling (mine are not always true...:\) that now is the right version..hmm..but also check the other one. maybe both are leaking.. this is the new: CallGetService(const char *aContractID, const nsIID &aIID, void **aResult) (mozilla\objs\xpcom\build\nsComponentManagerUtils.cpp) calls nsComponentManagerImpl::GetServiceByContractID(const char* aContractID, const nsIID& aIID, void* *result) in line 93. nsComponentManagerImpl::GetServiceByContractID(const char* aContractID, const nsIID& aIID, void* *result) (mozilla\xpcom\components\nsComponentManager.cpp) calls nsComponentManagerImpl::CreateInstanceByContractID(const char *aContractID, nsISupports *aDelegate, const nsIID &aIID, void **aResult) in line 2416 nsComponentManagerImpl::CreateInstanceByContractID(const char *aContractID, nsISupports *aDelegate, const nsIID &aIID, void **aResult) (same file) calls GetFactory(nsIFactory **aFactory, nsComponentManagerImpl * mgr) in line 1984 GetFactory(nsIFactory **aFactory, nsComponentManagerImpl * mgr) (mozilla\xpcom\components\nsComponentManager.h) calls nsNativeComponentLoader::GetFactory(const nsIID & aCID, const char *aLocation, const char *aType, nsIFactory **_retval) in line 302 ===> nsNativeComponentLoader::GetFactory(const nsIID & aCID, const char *aLocation, const char *aType, nsIFactory **_retval) (mozilla\xpcom\components\nsNativeComponentLoader.cpp) calls nsDll::Load(void) in line 123 btw, why was the bug resolved invalid?
Both paths of XPCOM load the component DLLs. I resolved INVALID because it's not a "leak" if it's by design.
You need to log in before you can comment on or make changes to this bug.