964362 - memcheck suppression files (delta from last October) for the latest TB (C-C)

Status: NEW

(Thunderbird :: General, defect)

Description

[ISHIKAWA, Chiaki]

Attachment: t-new-64.supp (delta of raw suppression rules for Debian GNU/Linux 64-bit)

I run valgrind semi-regularly to detect any
new memory-problems creeping into mozilla code.

My main target is thunderbird (c-c) since Firefox seems to have enough
eyeballs, and TB is my mailer. I need it to be a Rock-solid Mail
Client(tm).

Anyway, About every three months, I update my local suppression files
so that memory leak issues in various libraries and mozilla source code
can be suppressed invvalgrind output. 
Otherwise, the log becomes large (regularly 6+MB, but without proper suppression
can grow into 20+ MB!).
Many leaks are actually caused by the system-supplied
libraries outside of mozilla source code control.

I am uploading the delta of RAW suppression rules which were created
lately.  (These are new additional rules that have becomenecessary in the
latest C-C code fetched in January. The suppression files created in
last October could not suppress the new leaks.)

These rules are RAW in the sense that

 - the suppression rules are generated semi-automatically
   by an AWK script that reads a file of existing suppression rules
   and the valgrind (memcheck) output that contains the new leaks
   that could not be suppressed using the existing suppression rules.

   New leaks are collected and given new names automatically (after
   eliminating duplication).

   The only reason the script reads the old rules is to create a new
   non-conflicting name for a new rule automatically.

 - no optimization was done to catch common causes of leaks that share
   the common sequence of a few functions on the top of the stacktrace and
   to turn them into a single suppression rule.  

   So the number of rules is large :-(

   OTOH, you can see immediately that the leak is not bogus/false
   positive as far as valgrind is concerned: some leaks happen under a
   few different scenarios (i.e., calling sequences in the stack). So you
   become fairly confident that something fishy in the reported function on 
   the top of the stack. 

 - no optimization by using wild character match, |*| is done.  As a
   matter of fact, there seem to be many such chances to optimize the
   suppression rules.

The AWK script to create these new rules is dumb and does not handle
the optimizations mentioned above.

Also, the script does not handle the leaks that occur in external
libraries in a special manner: so the suppression rules for leaks in
mozilla code and external libraries are reported in a mixed manner.

The above is the reason why I call the uploaded rules are RAW.

With this caveat in mind, I am uploading as separate attachments the
new suppression rules that have become necessary to weed out the new
reported leaks by TB (C-C code) that was fetched in January (c-c).  
The log was captured during |make mozmill| test suite run of the DEBUG BUILD of
TB under valgrind.
The last time the suppression rules were updated locally on my PC was
October last year. So there are new leaks introduced by the change in
mozilla source code and system supplied libraries.

I have not especially picked out the leaks caused by mozilla-code.
So you have to examine the rules to figure out if it is mozilla-induced or not.

I was hesitant to post these because of the lack of optimization, but
seeing leaks from CompileFunctionBody() under 64-bit build many times
prompted me to report this.
(Funny, it is not reported under 32-bit!?)

The files uploaded are the deltas of RAW suppression files (rules
created to cover new leaks since last October).

Uploaded Suppression files created for Debian GNU/Linux  64-bit.

    t-new-64.supp         
    t-new-64.supp-demangle  <--- For convenience, I ran demangle so that
                               you can follow the function names easily.

    The following is the rules I found necessary on 32-bit 
    Debian GNU/Linux. Strangely, I don't think I found
    the CompileFunctionBody() leaks that was so conspicuous under 64-bit.
   (The source code fetch was date maybe one day off between 32-bit and 64-bit.
    That may explain it. Also, I may have updated the 32-bit later than the 64-bit version, thus including CompileFunctionBod() leak already?)

    t-new-32.supp
    t-new-32.supp-demangle 

One of these days, my main development machine is 64-bit Debian GNU/Linux so
I would like to say that 64-bit leak files are more useful and dependable.

But given that there seem to be subtle differences of leak behavior between
32-bit and 64-bit, and since 32-bit version is the official version,
I can only say that those who are familiar with
the suspect functions [at the top of the backtrace of leak supprression rule]
ought to take a look at.

Sorry I could not optimize the RAW rules files
for easier inspection. I simply don't have time for that.
Anyone?


TIA

PS; One more caveat: Valgrind/memcheck may report false positives.
What it thinks a "leak" of "definite" kind may, in fact, be legitimate
memory chunk that is left behind (although valgrind/memcheck DOES seem to
think that is a leak.)

Comment 1

[ISHIKAWA, Chiaki]

Attachment: t-new-64.supp-demangle (demangled version. Not for real use, but for easy inspection.)

Comment 2

[ISHIKAWA, Chiaki]

Attachment: t-new-32.supp (32-bit version)

Comment 3

[ISHIKAWA, Chiaki]

Attachment: t-new-32.supp-demangle

Comment 4

[ISHIKAWA, Chiaki]

I picked up thunderbird::general as the component (I could not find a suitable component after searching for about 20 minutes :-(