nsRegistry has a member variable, mReg of type HREG. nsRegistry::OpenWellKnownRegistry() calls NR_RegOpen(), which calls nr_RegOpen, which allocates memory for the HREG. That memory is never freed when nsRegistry is closed: 592 err = NR_RegClose( mReg ); 593 PR_Unlock(mregLock); 594 mReg = 0; It should just use the counter part of XP_ALLOC() there .. which should be fairly simple and looks to be painless.

Information on how often this occurs in various mozilla executions would help prioritize the bug.

In all likelihood, this is a very small one time leak. dveditz is likely to know better than I. If it makes it easier, I can submit a patch for this and go through the mozilla.org approval process. (cc'd dveditz for his commentary since he's wiser in the ways of the registry than I)

I only want to know the extent of the leak for priority so I know nsbeta3 or not. The fix is, as you point out, quite simple.

I am making this future until there is a reason not to.

libreg itself should free anything associated with HREG, after calling NR_RegClose() the registry handle is invalid. It's set to 0 here to prevent accidental reuse by nsRegistry, but the memory should be freed already. I just re-checked nr_RegClose(), and on line 2173 of reg.c there is an XP_FREE(reghnd) so this should be covered. So.... if you're seeing this leak that's pretty good evidence that someone is not closing a registry. The registry itself is closed and flushed at shutdown anyway (assuming NR_ShutdownRegistry() is called, which is supposed to happen when the component manager goes away), but that's sort of an emergency feature to make sure we don't loose data. Hm, maybe I'll put in an assertion for that case.

This sounds like a possible dup of the leaking nsRegistry bug that I've already filed then?

Edward: Welcome to xpcom!

Once again... attempting to reassign from Ray to Edward.

reassign all kandrot xpcom bug.

I'm not seeing a leaking nsRegistry according to the bloat logs. This bug looks a dup of bug 49563. *** This bug has been marked as a duplicate of 49563 ***