[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