809866 - nsImapMailDatabaseConstructor creates and leaves some data uninitialized (found by valgrind)

Status: NEW

(MailNews Core :: Networking: IMAP, defect)

Description

[ISHIKAWA, Chiaki]

Found by valgrind run. See bug 803816 about mozmill run of TB under valgrind.

Source version:

comm-central thunderbird.
$ hg identify
1016cef82fd8+ tip
ishikawa@debian-vm:~/TB-NEW/TB-3HG/new-src$ cd mozilla
ishikawa@debian-vm:~/TB-NEW/TB-3HG/new-src/mozilla$ hg identify
a517f7ea5bef+ tip

For full logs and annotated excerpts:

[1] Full log for valgrind run
   "still more log of valgrind run for classifying the problems "
   https://bug803816.bugzilla.mozilla.org/attachment.cgi?id=679654

[2] Annotated excerpt from the log
   "Manually inserted case ddd labeling to excerpted portion of the previous log."
   https://bug803816.bugzilla.mozilla.org/attachment.cgi?id=679655

I found from the valgrind run that the creation of data using the
following function leaves some variables in the object(?) or allocated
data structure (?) uninitialized which are later referenced and
valgrind prints warnings about it.

case 1 - 14: nsImapMailDatabaseConstructor issue

The part labeled as "CASE 2" in the annotated file [2] above shows
the problem as follows 

--- quote ---
CASE 2: RunScript -> Interpret 

     
==11344== Conditional jump or move depends on uninitialised value(s)
==11344==    at 0x66C7534: js::Interpret(JSContext*, js::StackFrame*, js::InterpMode) (jsapi.h:2694)
==11344==    by 0x66D18BC: js::RunScript(JSContext*, JS::Handle<JSScript*>, js::StackFrame*) (jsinterp.cpp:324)
==11344==    by 0x66D297F: js::InvokeKernel(JSContext*, JS::CallArgs, js::MaybeConstruct) (jsinterp.cpp:379)
==11344==    by 0x66D3047: js::Invoke(JSContext*, JS::Value const&, JS::Value const&, unsigned int, JS::Value*, JS::Value*) (jsinterp.h:109)
==11344==    by 0x6649E15: JS_CallFunctionValue (jsapi.cpp:5901)
==11344==    by 0x575DD25: nsXPCWrappedJSClass::CallMethod(nsXPCWrappedJS*, unsigned short, XPTMethodDescriptor const*, nsXPTCMiniVariant*) (XPCWrappedJSClass.cpp:1420)
==11344==    by 0x5756892: nsXPCWrappedJS::CallMethod(unsigned short, XPTMethodDescriptor const*, nsXPTCMiniVariant*) (XPCWrappedJS.cpp:580)
==11344==    by 0xBEE1B3E7: ???
==11344==  Uninitialised value was created by a heap allocation
==11344==    at 0x40271C4: malloc (vg_replace_malloc.c:270)

 ... the following part is fetched from the full log in [1] ...

==11344==    by 0x4041E10: moz_xmalloc (mozalloc.cpp:54)
==11344==    by 0x5B14432: nsImapMailDatabaseConstructor(nsISupports*, nsID const&, void**) (mozalloc.h:200)
==11344==    by 0x5FB8AB0: mozilla::GenericFactory::CreateInstance(nsISupports*, nsID const&, void**) (GenericFactory.cpp:16)
==11344==    by 0x5FEEAB5: nsComponentManagerImpl::CreateInstanceByContractID(char const*, nsISupports*, nsID const&, void**) (nsComponentManager.cpp:1006)
==11344==    by 0x5FB1AE8: CallCreateInstance(char const*, nsISupports*, nsID const&, void**) (nsComponentManagerUtils.cpp:138)
==11344==    by 0x5FB1B1E: nsCreateInstanceByContractID::operator()(nsID const&, void**) const (nsComponentManagerUtils.cpp:178)
==11344==    by 0x5FB0ED8: nsCOMPtr_base::assign_from_helper(nsCOMPtr_helper const&, nsID const&) (nsCOMPtr.cpp:110)
==11344==    by 0x5C5CA7A: nsMsgDBService::CreateNewDB(nsIMsgFolder*, nsIMsgDatabase**) (nsCOMPtr.h:603)
==11344==    by 0x5C87331: nsImapMailFolder::GetDatabase() (nsImapMailFolder.cpp:605)
==11344==    by 0x5C882AB: nsImapMailFolder::GetDBFolderInfoAndDB(nsIDBFolderInfo**, nsIMsgDatabase**) (nsImapMailFolder.cpp:2076)
==11344==


Observation.

A class object is created using the nsComponentManager mechanism, and
eventually the following function is called

	   nsImapMailDatabaseConstructor

But it seems that it leaves some variable(s) or data assigned to it
uninitialized. 

One of them is eventually referenced during the execution of
javascript interpreter and valgrind issues warning about a usage of
uninitialized value.

This should be fixed. 

I think all the data (including attributes in idl definition, etc.)
should be set to a known value, or a execution path should be checked
carefully to avoid such absence of proper initialization.