Closed
Bug 1396366
Opened 7 years ago
Closed 7 years ago
Crash in memcpy | mozilla::URLPreloader::WriteCache
Categories
(Core :: General, defect, P1)
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.
Updated•7 years ago
|
Flags: needinfo?(kmaglione+bmo)
Assignee | ||
Comment 1•7 years ago
|
||
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)
Updated•7 years ago
|
Priority: -- → P1
Comment hidden (mozreview-request) |
Comment 3•7 years ago
|
||
mozreview-review |
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
Comment 5•7 years ago
|
||
bugherder |
https://hg.mozilla.org/mozilla-central/rev/deef51eb0b7e
Status: NEW → RESOLVED
Closed: 7 years ago
Resolution: --- → FIXED
Target Milestone: --- → mozilla57
You need to log in
before you can comment on or make changes to this bug.
Description
•