This bug was filed from the Socorro interface and is report bp-6ac5ef52-5ee9-419b-b5e3-838a10170903. ============================================================= Crashing Thread (41), Name: SaveScripts Frame Module Signature Source 0 vcruntime140.dll memcpy f:\dd\vctools\crt\vcruntime\src\string\amd64\memcpy.asm:135 1 xul.dll mozilla::URLPreloader::WriteCache() js/xpconnect/loader/URLPreloader.cpp:229 2 xul.dll mozilla::ScriptPreloader::WriteCache() js/xpconnect/loader/ScriptPreloader.cpp:603 3 xul.dll mozilla::ScriptPreloader::Run() js/xpconnect/loader/ScriptPreloader.cpp:700 4 xul.dll nsThread::ProcessNextEvent(bool, bool*) xpcom/threads/nsThread.cpp:1039 5 xul.dll NS_ProcessNextEvent(nsIThread*, bool) xpcom/threads/nsThreadUtils.cpp:521 6 xul.dll mozilla::ipc::MessagePumpForNonMainThreads::Run(base::MessagePump::Delegate*) ipc/glue/MessagePump.cpp:338 7 xul.dll MessageLoop::RunHandler() ipc/chromium/src/base/message_loop.cc:319 8 xul.dll MessageLoop::Run() ipc/chromium/src/base/message_loop.cc:299 9 xul.dll nsThread::ThreadFunc(void*) xpcom/threads/nsThread.cpp:427 10 nss3.dll PR_NativeRunThread nsprpub/pr/src/threads/combined/pruthr.c:397 11 nss3.dll pr_root nsprpub/pr/src/md/windows/w95thred.c:95 12 ucrtbase.dll o__strtoui64 13 kernel32.dll BaseThreadInitThunk 14 ntdll.dll RtlUserThreadStart crashes with this signature started appearing on nightly after 57.0a1 build 20170902100317 where bug 1363482 has landed.

It looks like these are all shutdown crashes from very short sessions. There may be a race when we clear the URL cache after it's been written and the ScriptPreloader triggers a new write because the startup cache is flushed. That was never meant to trigger a second write of the URLCache, but there were a lot of changes to the ScriptPreloader between the time I wrote this and the time it landed.

Comment on attachment 8906109 [details] Bug 1396366: Make sure the URLPreloader cache is only written once. https://reviewboard.mozilla.org/r/177858/#review183386 LGTM. ::: js/xpconnect/loader/URLPreloader.cpp:211 (Diff revision 1) > + // its cache after a cache flush. We don't care about cache flushes, since > + // our cache doesn't store any file data, only paths. And we currently clear > + // our cached file list after the first write, which means that a second > + // write would (aside from breaking the invariant that we never touch > + // mCachedURLs off-main-thread after the first write, and trigger a data > + // race) mean we get no pre-loading on the next startup. Thanks for the thorough comment.

Pushed by maglione.k@gmail.com: https://hg.mozilla.org/integration/mozilla-inbound/rev/deef51eb0b7e Make sure the URLPreloader cache is only written once. r=erahm