I just got one of these in a try run of mine: https://treeherder.mozilla.org/logviewer.html#?job_id=167151568&repo=try&lineNumber=9952 looks related to the work done in bug 1425462... ClearOnShutdown is supposed to be main-thread only, and IIUC this can run from arbitrary threads: https://searchfox.org/mozilla-central/rev/44fa24847e4e73ce8932de4c8cf47559302e4ba2/toolkit/components/resistfingerprinting/nsRFPService.cpp#300 Which means ClearOnShutdown can race.

Should be fixed in the first patch of Bug 1443943 - should land that next week; unless you think it needs a fix ASAP.

(In reply to Tom Ritter [:tjr] from comment #1) > Should be fixed in the first patch of Bug 1443943 - should land that next > week; unless you think it needs a fix ASAP. This is causing a bunch of intermittents in browser tests, but yeah, if that lands soon I guess it's fine... One problem is, I guess that means that the race would be shipped in 60, maybe we should avoid that.

(In reply to Emilio Cobos Álvarez [:emilio] from comment #2) > (In reply to Tom Ritter [:tjr] from comment #1) > > Should be fixed in the first patch of Bug 1443943 - should land that next > > week; unless you think it needs a fix ASAP. > > This is causing a bunch of intermittents in browser tests, but yeah, if that > lands soon I guess it's fine... One problem is, I guess that means that the > race would be shipped in 60, maybe we should avoid that. There are a collection of Jitter bugs that are going to be uplifted to Beta, this is one of them.

We're going to land the first patch in bug 1443943 separately in this bug.

Before, we would initialize LRUCache on the first instance of calling the Timer Precision Reduction functions. We would both allocate and initialize it, and call ClearOnShutdown. ClearOnShutdown can only be called on the Main Thread, but it just so happened that we always did that, so there was no problem. Now that we are not calling precision reduction for system callers, we were initializing on a non-main-thread and we need to avoid that. In the future, we could reduce memory use IF we are not using the timer precision reduction functions by figuring out how to initialize this lazily but still on the main thread. For now, because we are using the timer precision reduction functions, doing so would not save us any memory.

https://hg.mozilla.org/integration/autoland/rev/65c4485ac92180077f8054ac4c51972115733ff5 https://hg.mozilla.org/mozilla-central/rev/65c4485ac921

Please request Beta approval on this when you're comfortable doing so.

Comment on attachment 8958524 [details] [diff] [review] Move LRUCache Initialization to startup rather than lazily. r=baku Approval Request Comment [Feature/Bug causing the regression]: The initial version of Jitter that landed (Bug 1425462) had a bug. [User impact if declined]: Crashes. [Is this code covered by automated tests?]: Indirectly, yes. In fact, they caught it. [Has the fix been verified in Nightly?]: Yes, it's baked for a few days [Needs manual test from QE? If yes, steps to reproduce]: No. [List of other uplifts needed for the feature/fix]: This blocks Bug 1443943 and Bug 1440195 which we also need to uplift. [Is the change risky?]: No. [Why is the change risky/not risky?]: There is always a risk I got the patch wrong, but it's been reviewed and people seem to think it's good. [String changes made/needed]: None

Comment on attachment 8958524 [details] [diff] [review] Move LRUCache Initialization to startup rather than lazily. r=baku sec fix, needed for other uplifts, beta60+