1396366 - Crash in memcpy | mozilla::URLPreloader::WriteCache

Status: RESOLVED FIXED

(Core :: General, defect, P1)

Description

[[:philipp]]

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.

Comment 1

[Kris Maglione [:kmag]]

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 2

[Kris Maglione [:kmag]]

Attachment: Bug 1396366: Make sure the URLPreloader cache is only written once.

Review commit: https://reviewboard.mozilla.org/r/177858/diff/#index_header
See other reviews: https://reviewboard.mozilla.org/r/177858/

Comment 3

[Eric Rahm [:erahm]]

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.

Comment 4

[Pulsebot]

Pushed by [e-mail]:
https://hg.mozilla.org/integration/mozilla-inbound/rev/deef51eb0b7e
Make sure the URLPreloader cache is only written once. r=erahm

Comment 5

[Sebastian Hengst [:aryx] (needinfo me if it's about an intermittent or backout)]

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