OLD | NEW |
(Empty) | |
| 1 # Stability Fixit Week |
| 2 |
| 3 The Chromium project tries hard to avoid bugs. |
| 4 We close the tree if even a tiny bug is detected by our continuous test suite. |
| 5 For bugs that can't be fixed right away, we file bug reports so developers can f
ix them offline. |
| 6 But after a while, the stack of crash and leak bug reports can be overwhelming |
| 7 for a single engineer to attack. So every now and then, we hold |
| 8 Stability Fixit Weeks so we can gang up on those bugs, and |
| 9 make some headway on the pile. |
| 10 |
| 11 We're especially interested in bugs taged with Fixit and Valgrind (click for lis
ts): |
| 12 * [Valgrind+Fixit](http://crbug.com/?can=2&q=label:Valgrind+Fixit&sort=-id) |
| 13 |
| 14 but any of the following could also use attention: |
| 15 * [Valgrind](http://crbug.com/?can=2&q=label:Valgrind&sort=-id) |
| 16 * [Crash](http://crbug.com/?can=2&q=label:crash&sort=-id) |
| 17 * [Regression](http://crbug.com/?can=2&q=label:regression&sort=-id) |
| 18 * [Fixit](http://crbug.com/?can=2&q=label:fixit&sort=-id) |
| 19 * [LinuxBeta](http://crbug.com/?can=2&q=label:Mstone-LinuxBeta&sort=-id) |
| 20 * [MacBeta](http://crbug.com/?can=2&q=label:Mstone-MacBeta&sort=-id) |
| 21 |
| 22 Memory leaks aren't as high priority as other sorts of Valgrind errors, but they
're still worth fixing. |
| 23 |
| 24 To work on Valgrind bugs, it helps to have the tool installed. |
| 25 |
| 26 Valgrind **is** free; see http://dev.chromium.org/developers/how-tos/using-valgr
ind for how to install and use it with Chrome on Mac and Linux. |
| 27 |
| 28 The bug reports usually name the test that exposed the problem; to |
| 29 reproduce the problem, you have to run the same test under Valgrind. |
| 30 That can be slow, and these bugs are subtle, so while you're waiting, try to und
erstand the bug by inspection of the source code. |
| 31 |
| 32 If the bug in question is already being suppressed, you may need to remove the s
uppression before you can see it. |
| 33 With Valgrind, it's easy to find and comment out suppressions; they're mostly in
tools/valgrind/memcheck/suppressions.txt, and every suppression has an associat
ed bug number. (Mac-specific suppressions are in a nearby file, suppressions\_m
ac.txt.) |
| 34 |
| 35 To try to reproduce a problem in a UI test named Foo.Bar with Valgrind, give the
command |
| 36 ``` |
| 37 tools/valgrind/chrome_tests.sh -t ui --gtest_filter=Foo.Bar |
| 38 ``` |
| 39 |
| 40 (Generally you should be in the chromium/src directory to run any of these tests
.) |
| 41 |
| 42 Layout tests are a bit different. |
| 43 |
| 44 To try to reproduce a problem in a test named LayoutTests/fast/loader/local-css-
from-local-html.html with Valgrind, you would give the command |
| 45 ``` |
| 46 tools/valgrind/valgrind_webkit_tests.sh LayoutTests/fast/loader/local-css-from-l
ocal-html.html |
| 47 ``` |
| 48 This will eventually produce output on stdout, but rather than wait, you can loo
k in the current directory for its temporary log files while it's still producin
g them. |
| 49 |
| 50 Sometimes problems only happen occasionally; you might want to write a little sc
ript to run your test in a loop. Or you might run a wide overnight fishing expe
dition to see if you can find any valgrind errors |
| 51 at all in one area of the tests. |
| 52 |
| 53 Note that the only kind of leak reports we care about from Valgrind are those ma
rked "definitely leaked". Ones marked "possibly leaked" should usually be ignor
ed. |
| 54 |
| 55 ## See Also |
| 56 |
| 57 * StabilizeTrunk |
| 58 * LayoutTestsLinux |
| 59 * LinuxDebugging |
| 60 * [RunningChromeUITests](RunningChromeUITests.md) |
| 61 * http://dev.chromium.org/developers/how-tos/using-valgrind |
| 62 * http://dev.chromium.org/developers/testing |
OLD | NEW |