Closed Bug 657349 Opened 9 years ago Closed 9 years ago

nsComponentManagerImpl leaks memory

Categories

(Core :: XPCOM, defect)

x86_64
Linux
defect
Not set

Tracking

()

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: 9 years ago
Resolution: --- → DUPLICATE
Duplicate of bug: 624870
Can we at least add a comment about this at the place that Valgrind complains, in an effort to avoid future duplicate reports?
You need to log in before you can comment on or make changes to this bug.