1067505 - The UnregisterWeakMemoryReporter() call in ~nsCategoryManager always fails

Status: RESOLVED FIXED

(Core :: XPCOM, defect)

Description

[Andrew McCreight [:mccr8]]

I was wondering why we were always getting this message on shutdown:
  WARNING: '!compMgr', file /Users/amccreight/mc/xpcom/glue/nsComponentManagerUtils.cpp, line 63

Turns out, ~nsCategoryManager calls UnregisterWeakMemoryReporter(), which calls do_GetService, but the category manager looks like a singleton being destroyed way late in shutdown, so do_GetService fails.  nsCategoryManager needs to either observe some XPCOM shutdown thing and call UnregisterWeakMemoryReporter() then, or just not try to Unregister.  I don't know the consequences of the latter.

Comment 1

[Nicholas Nethercote [inactive]]

> or just not try to Unregister.  I don't know the consequences of the latter.

Should be fine, so long as the registration is changed to RegisterStrongReporter. Then the memory reporter manager will free the reporter when it shuts down.

Comment 2

[Andrew McCreight [:mccr8]]

Attachment: Make nsCategoryManager into a strong memory reporter.

The nsCategoryManager singleton lives until very late in shutdown, so the unregister always fails.

It is okay to make it a strong reporter because it will always outlive the memory reporter manager anyways.

Comment 3

[Nicholas Nethercote [inactive]]

Comment on attachment 8491836 [details] [diff] [review]
Make nsCategoryManager into a strong memory reporter.

Review of attachment 8491836 [details] [diff] [review]:
-----------------------------------------------------------------

Have an r+.

Comment 4

[Andrew McCreight [:mccr8]]

Thanks!

https://hg.mozilla.org/integration/mozilla-inbound/rev/f9bfd3909264

green ish try run: https://tbpl.mozilla.org/?tree=Try&rev=ac371ef198ed

I think the oranges are unrelated to this patch.

Comment 5

[Andrew McCreight [:mccr8]]

Backed out for some kind of L64 debug make package failure:
  https://tbpl.mozilla.org/php/getParsedLog.php?id=48475634&tree=Mozilla-Inbound

https://hg.mozilla.org/integration/mozilla-inbound/rev/426bc4161af9

Presumably whatever weird way we're running embedded Gecko during packaging doesn't do something or other with the memory reporter manager in the right way.

Comment 6

[Andrew McCreight [:mccr8]]

Relanded because the leaks seem to be the fault of another push.

https://hg.mozilla.org/integration/mozilla-inbound/rev/f152a52a80e1

Comment 7

[Carsten Book [:Tomcat]]

https://hg.mozilla.org/mozilla-central/rev/f152a52a80e1