AddressSanitizer: A Fast Address Sanity Checker
2012 · paper · Computer science
Presents AddressSanitizer, a memory error detector that finds out-of-bounds accesses and use-after-free bugs in C and C++ programs. It reports an average slowdown of 73% and has found over 300 previously unknown bugs in the Chromium browser.
Checked: PDF from usenix.org, fetched 4 Oct 2026. Page numbers are those of that PDF.
2 findings
Substance The Section 3.4 stack example computes the shadow address as "(unsigned*)(((long)rz1>>8)+Offset);", but the paper's mapping is (Addr>>3)+Offset.
- p. 5 Section 3.4 transformed code
(unsigned*)(((long)rz1>>8)+Offset);
Judge's note: The page 5 image shows '>>8'. Sections 3.1 and 3.2 and the Appendix ('shr $0x3') all use a shift of 3. Section 3.1 limits Scale to 1..7, so 8 is not a valid Scale. The example's writes (shadow[0] covering 32-byte rz1 through a 4-byte unsigned, i.e. 4 shadow bytes x 8 bytes) only work with >>3.
Second check: another model agreed
Report a problem with this finding
Wording In every row of Table 1, the 'Increase' column is about 9/8 of Instrumented/Original (e.g. "400.perlbench 670 2168 3.64x", "total 8171 24467 3.37x"), and the paper does not say what the extra factor is.
- p. 6 Table 1, row 400.perlbench
670 2168 3.64x
- p. 6 Table 1, row 401.bzip2
858 1618 2.12x
- p. 6 Table 1, row 453.povray
17 371 24.55x
- p. 6 Table 1, total row
8171 24467 3.37x
Only the authors can say what is right here.
Judge's note: I read Table 1 on the page 6 image. Both MB columns sum exactly to the printed totals (8171 and 24467). Each printed ratio equals Instrumented/Original x 1.125. This suggests the ratio adds shadow memory (1/8) to the instrumented figure, but neither the caption nor the Section 4 text ('collected by reading the VmPeak field') says so. As printed, the ratio column cannot be reproduced from the columns beside it. Only the authors can say which is intended.
Second check: another model agreed
Report a problem with this finding
9 minor (typos and the like; most checked by the judge only)
Wording Section 4.1 says Duma "crashed on 12 out of 18 CPU2006 benchmarks" with 6 remaining, but Table 1 and Figure 2 cover 19 C/C++ CPU2006 benchmarks, and the paper does not say which one was left out of the Duma run.
- p. 7 Section 4.1
crashed on 12 out of 18
- p. 7 Section 4.1
On the remaining 6 benchmarks it showed
- p. 7 Section 4.1
crashed on 12 out of 18 CPU2006 benchmarks with out-of-memory errors
- p. 6 Table 1
482.sphinx3
Only the authors can say what is right here.
Judge's note: Table 1 on page 6 has 19 benchmark rows, and Figure 2 on page 7 shows 19 benchmarks. The page 7 text says 12 of 18, with 6 remaining. I found no explanation for leaving one benchmark out, so only the authors can say.
Second check: another model agreed
Report a problem with this finding
Wording The Section 5.3 checkN pseudocode makes the shift general, "ShadowAddr = (Addr >> Scale) + Offset;", and says Scale could be held in a special register, but keeps the Scale=3 mask "(Addr & 7)".
- p. 9 Section 5.3 pseudocode
ShadowAddr = (Addr >> Scale) + Offset;
Judge's note: Page 9 shows that only the shift is parameterised. Section 3.1 (page 3) says each shadow byte covers 2^Scale bytes and that Scale>3 needs more complex instrumentation. The in-granule offset mask 7 matches only Scale=3. This is a sketch, so I treat it as an observation.
Second check: another model agreed
Report a problem with this finding
Typo Section 3.1 misspells 'addressable' as "the first k bytes are addressible", although the same paragraph spells it 'addressable'.
- p. 3 Section 3.1, shadow encoding paragraph
the first k bytes are addressible
Judge's note: Checked on the page 3 image, in the shadow-byte encoding paragraph. Both 'addressable' and 'addressible' appear in that paragraph.
Second check: none (judge only)
Report a problem with this finding
Typo In Section 3.4 the original program declares "char a[10];" but the transformed code declares "char arr[10];", so the same array has two names.
- p. 4 Section 3.4 original program
char a[10];
- p. 5 Section 3.4 transformed code
char arr[10];
Judge's note: Page 4 shows 'char a[10];' in the original. Page 5 shows 'char arr[10];' in the transformed code, and the comments there say 'around arr'. This is a naming inconsistency between the two listings and has no technical effect.
Second check: none (judge only)
Report a problem with this finding
Typo In the Section 3.4 transformed code, "char rz1[32]" has no terminating semicolon, unlike the declarations that follow it.
- p. 5 Section 3.4 transformed code
char rz1[32]
Judge's note: The page 5 image shows 'char rz1[32]' with no semicolon, so this is not an extraction loss.
Second check: none (judge only)
Report a problem with this finding
Typo In Section 3.5 the closing quote around 'free' is an opening quotation mark: "between the “free“ and the following use".
- p. 5 Section 3.5
between the “free“ and the following use
Judge's note: The page 5 image (end of the left column) shows an opening-style quote where the closing quote should be.
Second check: none (judge only)
Report a problem with this finding
Typo The parentheses in the Section 5.3 checkN pseudocode are unbalanced: "if (k != 0 && ((Addr & 7) + N > k)".
- p. 9 Section 5.3
if (k != 0 && ((Addr & 7) + N > k)
Judge's note: The page 9 image shows 3 opening and 2 closing parentheses. The equivalent code in Section 3.2 (page 4) ends with 'k))'.
Second check: none (judge only)
Report a problem with this finding
Typo Reference [19] reads "Type-safe retrotting of legacy code. In Proc. of the , Principles of Programming Languages": the 'fi' is missing and there is an empty slot before the comma.
- p. 10 Reference [19]
Type-safe retrotting of legacy code. In Proc. of the , Principles of
Judge's note: The page 10 image shows both 'retrotting' and 'Proc. of the , Principles' as printed, so these are not extraction losses.
Second check: none (judge only)
Report a problem with this finding
Typo Reference [30] repeats the article: "In Proc. of the The International Symposium on Memory Management".
- p. 10 Reference [30]
In Proc. of the The International Symposium on Memory Management
Judge's note: The page 10 image shows 'the The' in reference [30].
Second check: none (judge only)