Open
Bug 964362
Opened 10 years ago
Updated 2 years ago
memcheck suppression files (delta from last October) for the latest TB (C-C)
Categories
(Thunderbird :: General, defect)
Tracking
(Not tracked)
NEW
People
(Reporter: ishikawa, Unassigned)
Details
Attachments
(4 files)
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.)
Reporter | ||
Comment 1•10 years ago
|
||
Reporter | ||
Comment 2•10 years ago
|
||
Reporter | ||
Comment 3•10 years ago
|
||
Reporter | ||
Updated•10 years ago
|
Component: Untriaged → General
Reporter | ||
Comment 4•10 years ago
|
||
I picked up thunderbird::general as the component (I could not find a suitable component after searching for about 20 minutes :-(
Updated•2 years ago
|
Severity: normal → S3
You need to log in
before you can comment on or make changes to this bug.
Description
•