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

RESOLVED INVALID

Status

()

Core
XPCOM
RESOLVED INVALID
13 years ago
13 years ago

People

(Reporter: Itay Perl, Assigned: dougt)

Tracking

({memory-leak})

Trunk
x86
Windows 2000
memory-leak
Points:
---

Firefox Tracking Flags

(Not tracked)

Details

(Reporter)

Description

13 years ago
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

13 years ago
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

13 years ago
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
(Reporter)

Comment 3

13 years ago
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 → ---

Comment 4

13 years ago
This bug needs to be resolved invalid or be changed
to the product that you ran BoundsChecker on.
(Reporter)

Comment 5

13 years ago
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.

Updated

13 years ago
Keywords: mlk

Comment 6

13 years ago
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
(Reporter)

Comment 7

13 years ago
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

13 years ago
Changed product/component to Core:XPCOM for investigation.
Assignee: firefox → dougt
Component: General → XPCOM
Product: Firefox → Core
QA Contact: general

Comment 9

13 years ago
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 ago13 years ago
Resolution: --- → INVALID
(Reporter)

Comment 10

13 years ago
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

13 years ago
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.