Problem adding sequence points to a method with portable PDB #840
Loading…
Reference in a new issue
No description provided.
Delete branch "%!s()"
Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?
Whenever I attempt to add a sequence point to a method with a portable PDB involved, the resulting PDB has a broken SequencePoints blob, resulting in
during processing, like when when hovering over the "SequencePoints" value when looking at the MethodDebugInformation table in ILSpy, or when running pdb2xml.
Looking at a before/after, for a case where I added only a single "hidden" (lines set to 0xfeefee) sequence point, the original blob contained 376 bytes:
and the new, broken one contains 386 bytes:
My gaze is drawn by that FFFFF8 sequence near the end. The method in question includes a "hidden" sequence point (string hashing code for a string-based
switch), so it can't be the 0xfeefee causing an issue there. My suspicion is that either the PDB writing code does not handle negative values correctly for a "compressed integer", or other processing results in a negative value when it shouldn't.Looking at the code that reads signed values back, the sign bit gets moved to the end. So if that 0xfffff849 is intended to be signed value -1975, I would expect to see something like 0x4f6f instead, if I read the code correctly (bit 0x40 in first byte to indicate: 2 bytes to read in total, then 0xf6f which is 1975 shifted left + the sign bit).
I'll try to make a minimal repro case, but hopefully this may already point in the right direction.
Note that while this issue prevents debugging in Visual Studio (because the entire PDB reading aborts), Rider is less affected (it seems to just silently discard the "bad" sequence points).
Looks like the problem is not so much the hidden sequence points - the sequence point records are emitted correctly.
However, the problem is that
SignatureWriter.WriteSequencePointsassumes thatMethodDebugInformation.SequencePointsis sorted by offset. However, that does not seem to be guaranteed. I'm not even certain that it's guaranteed that it would have duplicate offsets in it.I'll prepare a PR.