1020229 - valgrind/memgrind uninitialized memory issues for C-C thunderbird

Status: NEW

(Thunderbird :: General, defect)

Description

[ISHIKAWA, Chiaki]

Attachment: 9 pairs of stack trace leading to where the uninitialized memory is created, and memcheck suppression.

I ran valgrind/memcheck to C-C thunderbird last week.
Basically I ran |make mozmill| test suite of TB, and TB was run
under memcheck.

After combing through possibly new memory leaks, I noticed that a few
new uninitialized memory accesses (not noticed before) crept in in the
last few months.

I am attaching an edited excerpt from the log.

The names of the functions shown in memcheck's suggested suppression
template have been demangled by c++filt for easy reference.

Also, the template is preceded by the stack trace that leads up to
where the memory (uninitialized) was created (this is simply a copy of the
stack trace shown by memcheck.)

SUMMARY:

There were 9 pairs of stack trace and memcheck's suppression template.

Looking at where the uninitialized memory location was created, I recognize
three patterns.

(1), (3)  --- related to graphics library usage.

     gfxContext::PopGroup() (mozalloc.h:201)

     (Not sure if this TB -specific or a bug in the graphics library.)


(2), (4), (6) (7), (8), (9) --- related to mail DB stored in a file.

  nsMsgDBService::OpenMailDBFromFile(nsIFile*, nsIMsgFolder*, bool, bool, nsIMsgDatabase**) (mozalloc.h:201)

(5) MOZCRASH 

    This is related to MOZCRASH: not really an uninitialized issue.
    But it suggests that 
   mozilla::storage::Service::Observe(nsISupports*, char const*, char16_t const*)
   has a serious issue (null reference?). Maybe it does not have an Observer (==null) when the reference is made?

I will investigate the OpenMailDBFromFile() issue, first.

Looking at the memcheck's suggested suppression template, which reported
the uninitialized memory accesses in JavaScript interpreter functions,
I think an uninitialized variable or two in C++ code were passed to
JavaScript side (java interpreter) via XPCOM remote procedure call.
This happened before a few times.

TIA

(The attachment has the preamble which is the main text of this post.)

Comment 1

[Wayne Mery (:wsmwk)]

(this wouldn't be OS specific)