809883 - uninitialized data created by OpenMailDBFromFile

Status: RESOLVED WORKSFORME

(MailNews Core :: Backend, defect)

Description

[ISHIKAWA, Chiaki]

uninitialized data created by OpenMailDBFromFile


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.

	 OpenMailDBFromFile

case 23 - 29: OpenMailDBFromFile issue	(to be filed)

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

--- quote ---
CASE 23: A "new"ed object seems to have uninitialized data.: InitDB(nsIMsgDatabase*)
     nsFolderCompactState::InitDB(nsIMsgDatabase*) (nsMsgFolderCompactor.cpp:109)

==13533== Conditional jump or move depends on uninitialised value(s)
==13533==    at 0x573E29B: XPCConvert::NativeData2JS(XPCLazyCallContext&, JS::Value*, void const*, nsXPTType const&, nsID const*, tag_nsresult*) (jsapi.h:2170)
==13533==    by 0xC31814F: ???
==13533==  Uninitialised value was created by a heap allocation
==13533==    at 0x40271C4: malloc (vg_replace_malloc.c:270)
==13533==    by 0x4041E10: moz_xmalloc (mozalloc.cpp:54)
==13533==    by 0x5C61890: nsMsgDBService::OpenMailDBFromFile(nsIFile*, nsIMsgFolder*, bool, bool, nsIMsgDatabase**) (mozalloc.h:200)
==13533==    by 0x5B7859A: nsFolderCompactState::InitDB(nsIMsgDatabase*) (nsMsgFolderCompactor.cpp:109)
==13533==    by 0x5B78EB3: nsFolderCompactState::Init(nsIMsgFolder*, char const*, nsIMsgDatabase*, nsIFile*, nsIMsgWindow*) (nsMsgFolderCompactor.cpp:271)
==13533==    by 0x5B7A337: nsFolderCompactState::Compact(nsIMsgFolder*, bool, nsIUrlListener*, nsIMsgWindow*) (nsMsgFolderCompactor.cpp:215)
==13533==    by 0x5B79510: nsFolderCompactState::CompactNextFolder() (nsMsgFolderCompactor.cpp:602)

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

==13533==    by 0x5B79D90: nsFolderCompactState::FinishCompact() (nsMsgFolderCompactor.cpp:533)
==13533==    by 0x5B790F6: nsFolderCompactState::StartCompacting() (nsMsgFolderCompactor.cpp:363)
==13533==    by 0x11: ???
==13533==


--- end quote ---


Observation.

A class object(?) is created using the following function :

	   OpenMailDBFromFile

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 should be initialized on allocation or
execution path ought to be checked carefully so that
such absence of initialization is avoided.

Comment 1

[Wayne Mery (:wsmwk)]

obsolete?

Comment 2

[ISHIKAWA, Chiaki]

It probably is.
The last time it was seen on my local log is in 2016.

If I can run TB's mochitest under valgrind again and see this bug reappear, I will re-open this.