Closed Bug 767406 Opened 8 years ago Closed 8 years ago

Uninitialised value use in mozilla::scache::StartupCache::WriteToDisk()

Categories

(Core :: XPCOM, defect)

defect
Not set
normal

Tracking

()

RESOLVED FIXED
mozilla19

People

(Reporter: jseward, Assigned: froydnj)

Details

(Keywords: valgrind)

Attachments

(1 file, 1 obsolete file)

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)
FWIW, it looks like ~StartupCache always expects StartupCache::Init to succeed.  That's not a good assumption.
Component: Networking: Cache → XPCOM
QA Contact: networking.cache → xpcom
Assignee: nobody → hurley
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
Assignee: hurley → nobody
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
Attached patch patch (obsolete) — Splinter Review
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 on attachment 669965 [details] [diff] [review]
patch

Can we check mTable.IsInitialized() ?
Attached patch patchSplinter Review
(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 on attachment 670105 [details] [diff] [review]
patch

Much better. :)
Attachment #670105 - Flags: review?(mwu) → review+
https://hg.mozilla.org/integration/mozilla-inbound/rev/ac7e592b097c
Assignee: nobody → nfroyd
Status: NEW → ASSIGNED
OS: Linux → All
Hardware: x86_64 → All
https://hg.mozilla.org/mozilla-central/rev/ac7e592b097c
Status: ASSIGNED → RESOLVED
Closed: 8 years ago
Resolution: --- → FIXED
Target Milestone: --- → mozilla19
You need to log in before you can comment on or make changes to this bug.