Closed Bug 657349 Opened 13 years ago Closed 13 years ago

nsComponentManagerImpl leaks memory

Categories

(Core :: XPCOM, defect)

Product:
Core
Component:
XPCOM
Platform:
x86_64
Linux
Type:
defect
Priority:
Not set
Severity:
normal

Tracking

()

Status:
RESOLVED DUPLICATE of bug 624870

People

(Reporter: jseward, Unassigned)

References

Details

Visible for any startup/quit of M-C.  Is this the same as 
bug 53932 (nsComponentManagerImpl leaks nsComponentManagerLog, which
is RESOLVED WONTFIX) ?

20,448 bytes in 639 blocks are definitely lost in loss record 6,798 of 6,807
   at 0x4C2787A: malloc (/home/sewardj/VgTRUNK/trunk/coregrind/m_replacemalloc/vg_replace_malloc.c:236)
   by 0x74DE15B: moz_xmalloc (memory/mozalloc/mozalloc.cpp:100)
   by 0x6462746: nsComponentManagerImpl::RegisterCIDEntry(mozilla::Module::CIDEntry const*, nsComponentManagerImpl::KnownModule*) (ff-opt/xpcom/components/../../dist/include/mozilla/mozalloc.h:229)
   by 0x6463161: nsComponentManagerImpl::RegisterModule(mozilla::Module const*, nsILocalFile*) (xpcom/components/nsComponentManager.cpp:446)
   by 0x64638A3: nsComponentManagerImpl::Init() (xpcom/components/nsComponentManager.cpp:386)
   by 0x642AA44: NS_InitXPCOM2_P (xpcom/build/nsXPComInit.cpp:515)
   by 0x561D240: ScopedXPCOMStartup::Initialize() (toolkit/xre/nsAppRunner.cpp:1148)
   by 0x5620AB1: XRE_main (toolkit/xre/nsAppRunner.cpp:3451)
   by 0x400E4A: main (browser/app/nsBrowserApp.cpp:159)
I think so.
No, this is separate: we intentionally leak these objects because they have app lifetime and freeing them is potentially dangerous.
Status: NEW → RESOLVED
Closed: 13 years ago
Resolution: --- → DUPLICATE
Can we at least add a comment about this at the place that Valgrind complains, in an effort to avoid future duplicate reports?
No longer blocks: mlk-fx5+
You need to log in before you can comment on or make changes to this bug.