I see this too, on opt builds. It looks from the code like something is calling registerTimer after profile-before-change has already fired. I guess ideally we should both (a) fix the consumer not to do that (ie this might be a bigger bug than just the logspam, if whatever it's trying to schedule is actually important or if it's still trying to do initialization even though the process is dying) and (b) fix registerTimer to throw a more descriptive error if it gets called when _timers is already null.
This is likely due to in part bug 1375077 which shuts nsUpdatetimerManager down earlier than we used to and it appears that when running tests profile-before-change is sent before the application is shutting down. Option b is a no brainer and I don't think option a will provide any value in the non test world where all notifications are sent... at worst the component fails after it has already shut down.
Note: the registration id is telemetry_modules_ping
This delayed task is the likely culprit http://searchfox.org/mozilla-central/source/toolkit/components/telemetry/TelemetryController.jsm#717 which then calls http://searchfox.org/mozilla-central/source/toolkit/components/telemetry/TelemetryController.jsm#748 and here is the function that registers the timer http://searchfox.org/mozilla-central/source/toolkit/components/telemetry/TelemetryModules.jsm#41
Created attachment 8883757 [details] [diff] [review] patch rev1
chutten, just an fyi that telemetry's registerTimer call is reporting an error in tests due to it delaying until after profile-before-change is called. See comment #4 for more details.
Created attachment 8883762 [details] [diff] [review] patch rev2 While I'm here I switched the inconsistent though valid logging style that was recently added as well as fixed a typo in the log message.
Pushed by email@example.com: https://hg.mozilla.org/integration/mozilla-inbound/rev/39e61f5e8fc5 Don't try to register timers during shutdown in nsUpdateTimerManager.js. r=mhowell
Good to know. +ni Dexter, gfritzsche for visibility.
Thanks. For this specific call, this seems non-critical. Unless there is specific impact this seems fine to leave as is (with the error being handled in the update timer manager now).
+ Marco (FYI)