Closed Bug 1396366 Opened 2 years ago Closed 2 years ago

Crash in memcpy | mozilla::URLPreloader::WriteCache

Categories

(Core :: General, defect, P1, critical)

57 Branch
defect

Tracking

()

RESOLVED FIXED
mozilla57
Tracking Status
firefox-esr52 --- unaffected
firefox55 --- unaffected
firefox56 --- unaffected
firefox57 --- fixed

People

(Reporter: philipp, Assigned: kmag)

References

Details

(Keywords: crash, regression)

Crash Data

Attachments

(1 file)

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.
Flags: needinfo?(kmaglione+bmo)
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.
Assignee: nobody → kmaglione+bmo
Flags: needinfo?(kmaglione+bmo)
Blocks: 1397035
Priority: -- → P1
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.
Attachment #8906109 - Flags: review?(erahm) → review+
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
https://hg.mozilla.org/mozilla-central/rev/deef51eb0b7e
Status: NEW → RESOLVED
Closed: 2 years ago
Resolution: --- → FIXED
Target Milestone: --- → mozilla57
Duplicate of this bug: 1396253
Duplicate of this bug: 1398794
Duplicate of this bug: 1398926
Duplicate of this bug: 1397606
Duplicate of this bug: 1397199
Duplicate of this bug: 1397464
Duplicate of this bug: 1397465
Duplicate of this bug: 1397035
Duplicate of this bug: 1400552
Duplicate of this bug: 1398568
You need to log in before you can comment on or make changes to this bug.