Closed
Bug 767406
Opened 10 years ago
Closed 10 years ago
Uninitialised value use in mozilla::scache::StartupCache::WriteToDisk()
Categories
(Core :: XPCOM, defect)
Core
XPCOM
Tracking
()
RESOLVED
FIXED
mozilla19
People
(Reporter: jseward, Assigned: froydnj)
Details
(Keywords: valgrind)
Attachments
(1 file, 1 obsolete file)
891 bytes,
patch
|
mwu
:
review+
|
Details | Diff | Splinter Review |
TEST_PATH=dom/browser-element/mochitest/test_browserElement_oop_Alert.html gives the complaint below. This also happens on B2G, every time I start up a content process (I think .. not sure). Conditional jump or move depends on uninitialised value(s) at 0x53C5025: mozilla::scache::StartupCache::WriteToDisk() (StartupCache.cpp:418) by 0x53C5462: mozilla::scache::StartupCache::~StartupCache() (StartupCache.cpp:136) by 0x53C5A1A: mozilla::scache::StartupCache::InitSingleton() (StartupCache.cpp:112) by 0x53C5A5C: mozilla::scache::StartupCache::GetSingleton() (StartupCache.cpp:93) by 0x606A150: NS_InitXPCOM2_P (nsXPComInit.cpp:493) by 0x52A2C26: XRE_InitEmbedding2 (nsEmbedFunctions.cpp:157) by 0x5F85B1C: mozilla::ipc::ScopedXREEmbed::Start() (ScopedXREEmbed.cpp:83) by 0x5F567DE: mozilla::dom::ContentProcess::Init() (ContentProcess.cpp:22) by 0x52A2FDA: XRE_InitChildProcess (nsEmbedFunctions.cpp:474) by 0x401A8C: main (MozillaRuntimeMain.cpp:48) Uninitialised value was created by a heap allocation at 0x402AC1B: malloc (vg_replace_malloc.c:268) by 0x4060EFB: moz_xmalloc (mozalloc.cpp:54) by 0x53C59DE: mozilla::scache::StartupCache::InitSingleton() (mozalloc.h:200) by 0x53C5A5C: mozilla::scache::StartupCache::GetSingleton() (StartupCache.cpp:93) by 0x606A150: NS_InitXPCOM2_P (nsXPComInit.cpp:493) by 0x52A2C26: XRE_InitEmbedding2 (nsEmbedFunctions.cpp:157) by 0x5F85B1C: mozilla::ipc::ScopedXREEmbed::Start() (ScopedXREEmbed.cpp:83) by 0x5F567DE: mozilla::dom::ContentProcess::Init() (ContentProcess.cpp:22) by 0x52A2FDA: XRE_InitChildProcess (nsEmbedFunctions.cpp:474) by 0x401A8C: main (MozillaRuntimeMain.cpp:48)
![]() |
Assignee | |
Comment 1•10 years ago
|
||
FWIW, it looks like ~StartupCache always expects StartupCache::Init to succeed. That's not a good assumption.
Updated•10 years ago
|
Component: Networking: Cache → XPCOM
QA Contact: networking.cache → xpcom
Reporter | ||
Comment 2•10 years ago
|
||
This is still present in current m-c, and observable on x86_64-linux, using TEST_PATH=content/base/test/test_ipc_messagemanager_blob.html
Reporter | ||
Comment 3•10 years ago
|
||
Any suggestions who can take this? It's still alive and well in m-c and I'd like to get rid of it.
Keywords: valgrind
![]() |
Assignee | |
Comment 4•10 years ago
|
||
This is one way to handle the problem: flag that the relevant tables have been initialized before checking them in WriteToDisk. The other possibility is to initialize the tables in the constructor, rather than in Init. I am not sure if that would be compatible with The Gecko Way. Maybe it's OK because our hashtables are now infallible by default and we'd just throw during the constructor if the hashtable.Init() call failed?
Attachment #669965 -
Flags: review?(mwu)
Comment 5•10 years ago
|
||
Comment on attachment 669965 [details] [diff] [review] patch Can we check mTable.IsInitialized() ?
![]() |
Assignee | |
Comment 6•10 years ago
|
||
(In reply to Michael Wu [:mwu] from comment #5) > Can we check mTable.IsInitialized() ? We certainly can; that's a much better idea. How about this patch?
Attachment #669965 -
Attachment is obsolete: true
Attachment #669965 -
Flags: review?(mwu)
Attachment #670105 -
Flags: review?(mwu)
Comment 7•10 years ago
|
||
Comment on attachment 670105 [details] [diff] [review] patch Much better. :)
Attachment #670105 -
Flags: review?(mwu) → review+
![]() |
Assignee | |
Comment 8•10 years ago
|
||
https://hg.mozilla.org/integration/mozilla-inbound/rev/ac7e592b097c
Assignee: nobody → nfroyd
Status: NEW → ASSIGNED
OS: Linux → All
Hardware: x86_64 → All
Comment 9•10 years ago
|
||
https://hg.mozilla.org/mozilla-central/rev/ac7e592b097c
Status: ASSIGNED → RESOLVED
Closed: 10 years ago
Resolution: --- → FIXED
Target Milestone: --- → mozilla19
You need to log in
before you can comment on or make changes to this bug.
Description
•