[cfe-dev] Announcing "clang-ctags"

[Douglas Gregor]

On Jul 25, 2012, at 2:41 AM, Manuel Klimek <klimek at google.com> wrote:

> On Wed, Jul 25, 2012 at 12:14 AM, Sean Silva <silvas at purdue.edu> wrote:
>> I saw the bug report, but that gives only memory addresses and
>> instruction offsets for what the offending code is (`0x1048b50b1 in
>> (anonymous namespace)::ASTStatCache::getStat(char const*,
>> stat&, int*) (in clang-tags) + 977`); given the size of `getStat` and
>> a brief perusal of the source, it seems like at least one level of
>> inlining is involved. It would be immensely helpful if you could tie
>> that address back to the statement/expression which causes the
>> reference.
> 
> Also, as noted on the bug, the Tooling should never pull in
> ASTStatCache. Any pointers to how that might be instantiated would be
> of great help.


I suspect this is what is happening:

  - Clang is loading a precompiled header, which wires a stat cache into the FileManager. That stat cache points into the mmap'd memory for the precompiled header.
  - That instance of the compiler completes, and everything goes away *except* the stat cache, since the FileManager is reused. We now have a stat cache in the FileManager that points at the location of previously-mmap'd memory for the precompiled header.
  - Later instances of the compiler wire more stat caches into the FileManager, and most lookups hit those earlier caches, so the problem doesn't reproduce easily
  - Eventually, we have a cache miss in a later instance of the compiler, and the dangling pointer into the previously-mmap'd precompiled header ends up getter used after those addresses have been reused, and BOOM!
  
Solution: clear out the stat caches attached to the FileManager when re-using that file manager.

	- Doug