Some glyphs in DejaVuSans.ttf version 2.37 have invalid bytecode which affects the rendering of other glyphs.

For example, if you render glyphs with FreeType in particular order, the bitmap can be 1 px larger than expected. Here is the program to test the issue:
  https://gist.github.com/danpla/35292c7c54fc1217b81219aa442dcc37

Compile it with FreeType 2.7.0 or newer and run with DejaVuSans.ttf at 100 pt. It will give the following:

  FreeType 2.8.1
  Loading DejaVuSans.ttf at 100 pt
  Checking cbox vs bbox

  Checking bitmap vs cbox
  U+07ED bitmap > cbox: {11, 10} > {11, 9}
  U+07F2 bitmap > cbox: {10, 10} > {10, 9}
  U+07F3 bitmap > cbox: {30, 10} > {30, 9}
  U+07F8 bitmap > cbox: {48, 50} > {48, 49}

Among 583 fonts I tested, DejaVu Sans is the only one that has this problem.

We discussed this issue on FreeType mailing list, and here is a quote from a FreeType developer:

> This is a font bug.  The bytecode of glyph `uni2751' in the font is
> not fully encapsulated, causing side effects to other glyphs: It
> modifies CVT entries with indices 3, 8, 0, and 6, setting them to a
> large value (250px).  However, the bytecode of glyph `uni07ED' (and
> probably the other three glyphs also) uses CVT entry with index 8,
> too: If this CVT value is smaller than 10px (the `CVT cut-in', as set
> up in this font for 100ppem), the original, rounded value gets used as
> the distance between the top and the bottom points (which is 9px),
> otherwise the CVT cut-in value gets used, which is 10px.
> 
> In other words: If you load U+07ED, then U+2751, then U+07ED again,
> you get an 11x10 bitmap instead of an 11x9 size.
> 
> It's not easy to say which glyph's bytecode is incorrect.  In general,
> CVT values shouldn't be modified by glyph bytecode, otherwise you have
> global effects, which is undesirable in most cases – as you have
> detected.  It's rather the job of the `prep' table to properly set up
> CVT values.