summaryrefslogtreecommitdiffstats
path: root/docs/retrieving_code_analysis_warnings.md
blob: a59e6964bdf5f9b890f7b3d1b06dcd0feab0f84d (plain)
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
# Retrieving Code Analysis Warnings

Several times a day the Chromium code base is built with Microsoft VC++'s
`/analyze` compile option. This does static code analysis which has found
numerous bugs (see https://crbug.com/427616). While it is possible to visit the
`/analyze` builder page and look at the raw results
(http://build.chromium.org/p/chromium.fyi/builders/Chromium%20Windows%20Analyze)
this works very poorly.

As of this writing there are 2,702 unique warnings. Some of these are in header
files and fire multiple times so there are a total of 11,202 warning lines. Most
of these have been examined and found to be false positives. Therefore, in order
to sanely examine the /analyze warnings it is necessary to summarize the
warnings, and find what is new.

There are scripts to do this.

## Details

The necessary scripts, which currently run on Windows only, are checked in to
`tools\win\new_analyze_warnings`. Typical usage is like this:

    > set ANALYZE_REPO=d:\src\analyze_chromium
    > retrieve_latest_warnings.bat

The batch file using the associated Python scripts to retrieve the latest
results from the web page, create a summary file, and if previous results were
found create a new warnings file. Typical results look like this:

    analyze0067_full.txt
    analyze0067_summary.txt
    analyze0067_new.txt

If `ANALYZE_REPO` is set then the batch file goes to `%ANALYZE_REPO%\src`, does
a git pull, then does a checkout of the revision that corresponds to the latest
warnings, and then does a gclient sync. The warnings can then be easily
correlated to the specific source that triggered them.

## Understanding the results

The `new.txt` file lists new warnings, and fixed warnings. Usually it can
accurately identify them but sometimes all it can say is that the number of
instances of a particularly warning has changed, which is usually not of
interest. If you look at new warnings every day or two then the number of new
warnings is usually low enough to be quite manageable.

The `summary.txt` file groups warnings by type, and then sorts the groups by
frequency. Low frequency warnings are more likely to be real bugs, so focus on
those. However, all of the low-frequency have been investigated so at this time
they are unlikely to be real bugs.

The majority of new warnings are variable shadowing warnings. Until `-Wshadow`
is enabled for gcc/clang builds these warnings will continue to appear, and
unless they are actually buggy or are particularly confusing it is usually not
worth fixing them. One exception would be if you are planning to enable
`-Wshadow` in which case using the list or relevant shadowing warnings would be
ideal.

Some of the warnings say that out-of-range memory accesses will occur, which is
pretty scary. For instance "warning C6201: Index '-1' is out of valid index
range '0' to '4'". In most cases these are false positives so use your own
judgment when deciding whether to fix them.

The `full.txt` file contains the raw output and should usually be ignored.

If you have any questions then post to the chromium dev mailing list.