289882 - Memory Leak: Library Loaded with LoadLibrary and was never freed with FreeLibrary - mozilla\nsprpub\pr\src\linking\prlink.c

Status: RESOLVED INVALID

(Core :: XPCOM, defect)

Description

[Itay Perl]

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

Comment 1

[Julien Pierre]

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.

Comment 2

[Wan-Teh Chang]

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.

Comment 3

[Itay Perl]

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)

Comment 4

[Wan-Teh Chang]

This bug needs to be resolved invalid or be changed
to the product that you ran BoundsChecker on.

Comment 5

[Itay Perl]

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.

Comment 6

[Wan-Teh Chang]

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.

Comment 7

[Itay Perl]

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

Comment 8

[Wan-Teh Chang]

Changed product/component to Core:XPCOM for investigation.

Comment 9

[Benjamin Smedberg]

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.

Comment 10

[Itay Perl]

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?

Comment 11

[Benjamin Smedberg]

Both paths of XPCOM load the component DLLs. I resolved INVALID because it's not
a "leak" if it's by design.