809887 - uninitialized data created by nsNewsDatabaseConstructor

Status: RESOLVED WORKSFORME

(Thunderbird :: General, 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.

	 nsNewsDatabaseConstructor

case 30 - 36: nsNewsDatabaseConstructor issue 

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

--- quote ---

CASE 33: not sure  RunScript -> Interpret 

==14614== Conditional jump or move depends on uninitialised value(s)
==14614==    at 0x66C75D6: js::Interpret(JSContext*, js::StackFrame*, js::InterpMode) (FloatingPoint.h:237)
==14614==    by 0x66D18BC: js::RunScript(JSContext*, JS::Handle<JSScript*>, js::StackFrame*) (jsinterp.cpp:324)
==14614==    by 0x66D297F: js::InvokeKernel(JSContext*, JS::CallArgs, js::MaybeConstruct) (jsinterp.cpp:379)
==14614==    by 0x66D3047: js::Invoke(JSContext*, JS::Value const&, JS::Value const&, unsigned int, JS::Value*, JS::Value*) (jsinterp.h:109)
==14614==    by 0x6649E15: JS_CallFunctionValue (jsapi.cpp:5901)
==14614==    by 0x575DD25: nsXPCWrappedJSClass::CallMethod(nsXPCWrappedJS*, unsigned short, XPTMethodDescriptor const*, nsXPTCMiniVariant*) (XPCWrappedJSClass.cpp:1420)
==14614==    by 0x5756892: nsXPCWrappedJS::CallMethod(unsigned short, XPTMethodDescriptor const*, nsXPTCMiniVariant*) (XPCWrappedJS.cpp:580)
==14614==    by 0x79C0464: g_main_context_check (in /lib/i386-linux-gnu/libglib-2.0.so.0.3200.4)
==14614==    by 0x575670A: nsXPCWrappedJS::AddRef() (XPCWrappedJS.cpp:155)
==14614==    by 0x575670A: nsXPCWrappedJS::AddRef() (XPCWrappedJS.cpp:155)

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

==14614==    by 0x4FFFF: ???
==14614==  Uninitialised value was created by a heap allocation
==14614==    at 0x40271C4: malloc (vg_replace_malloc.c:270)
==14614==    by 0x4041E10: moz_xmalloc (mozalloc.cpp:54)
==14614==    by 0x5B144C5: nsNewsDatabaseConstructor(nsISupports*, nsID const&, void**) (mozalloc.h:200)
==14614==    by 0x5FB8AB0: mozilla::GenericFactory::CreateInstance(nsISupports*, nsID const&, void**) (GenericFactory.cpp:16)
==14614==    by 0x5FEEAB5: nsComponentManagerImpl::CreateInstanceByContractID(char const*, nsISupports*, nsID const&, void**) (nsComponentManager.cpp:1006)
==14614==    by 0x5FB1AE8: CallCreateInstance(char const*, nsISupports*, nsID const&, void**) (nsComponentManagerUtils.cpp:138)
==14614==    by 0x5FB1B1E: nsCreateInstanceByContractID::operator()(nsID const&, void**) const (nsComponentManagerUtils.cpp:178)
==14614==    by 0x5FB0ED8: nsCOMPtr_base::assign_from_helper(nsCOMPtr_helper const&, nsID const&) (nsCOMPtr.cpp:110)
==14614==    by 0x5C5CA7A: nsMsgDBService::CreateNewDB(nsIMsgFolder*, nsIMsgDatabase**) (nsCOMPtr.h:603)
==14614==    by 0x5D48A3C: nsMsgNewsFolder::GetDatabase() (nsNewsFolder.cpp:352)
==14614==    by 0x5D46242: nsMsgNewsFolder::GetDBFolderInfoAndDB(nsIDBFolderInfo**, nsIMsgDatabase**) (nsNewsFolder.cpp:768)
==14614==


--- end quote ---


Observation.

A class object(?) is created using the following function within the
framework of nsComponent manager:

	 nsNewsDatabaseConstructor

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. 

The data (including attributes in *.idl file) should be initialized on
allocation or execution path ought to be checked carefully so that
such absence of initialization is avoided.

Comment 1

[ISHIKAWA, Chiaki]

This bug is no longer visible. 
It must have been solved by the missing proper initialization of some date-related data upon the creation of database.
(can't locate that particular bug easily.)