Open Zastai opened 2 years ago
Zastai
commented
2 years ago 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).
Zastai
commented
2 years ago 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.WriteSequencePoints assumes that MethodDebugInformation.SequencePoints is 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.
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.