[PATCH] D41734: [DebugInfo][PDB] Fix too many FPM blocks being written in some cases

Zachary Turner via Phabricator via llvm-commits llvm-commits at lists.llvm.org
Thu Jan 4 12:55:56 PST 2018


zturner added a comment.

In https://reviews.llvm.org/D41734#967572, @zturner wrote:

> So this is interesting:
>
> https://github.com/Microsoft/microsoft-pdb/blob/master/PDB/msf/msf.cpp#L1663-L1695
>
> Especially the part about "Mark all non-special pages free".  But then it just says `setAll();`  Maybe this backs up your theory that the first 3 pages are "special" and so they are always allocated and excluded from the FPM entirely.
>
> Would this mean that the 8 bits in the first byte of the first page of the FPM actually refer to pages [3,11) in the underlying MSF file?


Ok, now I definitely think the first 3 pages **are** included in the FPM.  I'm looking at this code <https://github.com/Microsoft/microsoft-pdb/blob/master/PDB/msf/msf.cpp#L1680-L1683>:

This code gets run upon initialization of a new MSF.

  for (UPN pn = 0; pn < msfparms.pnDataMin; pn++) {
      if (fpm.nextPn() != pn)
          assert(FALSE);
  }

here, `pnDataMin == 3`, and `fpm.nextPn()` basically means "mark this page allocated in the bitmap".  So this code translates to:

  fpm.setAllocated(0);
  fpm.setAllocated(1);
  fpm.setAllocated(2);

So the FPM is definitely recording information about these 3 pages.

I'm going to inspect the code that crashed in `WritableMappedBlockStream::writeBytes` and see if maybe there's something there.

Is there a reliable way to repro this crash?


Repository:
  rL LLVM

https://reviews.llvm.org/D41734





More information about the llvm-commits mailing list