Description
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
System.BadImageFormatException: Invalid compressed integer.
at System.Reflection.Throw.InvalidCompressedInteger()
at System.Reflection.Metadata.SequencePointCollection.Enumerator.MoveNext()
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:
01-00-00-19-80-D8-07-05-00-1D-10-00-05-02-24-06
00-51-00-5D-18-00-25-00-4B-02-00-20-00-35-04-00
1F-00-3A-0A-00-16-00-00-81-2F-00-36-04-08-1F-00
34-02-00-1A-00-24-02-00-11-00-34-02-00-1A-00-24
02-00-11-00-06-02-00-01-00-36-04-00-1F-00-34-02
00-1A-00-24-02-00-11-00-34-02-00-1A-00-24-02-00
11-00-06-02-00-01-00-36-04-00-1F-00-34-02-00-1A
00-24-02-00-11-00-34-02-00-1A-00-24-02-00-11-00
06-02-00-01-00-36-04-00-1F-00-34-02-00-1A-00-24
02-00-11-00-34-02-00-1A-00-24-02-00-11-00-06-02
00-01-00-36-04-00-1F-00-34-02-00-1A-00-24-02-00
11-00-34-02-00-1A-00-24-02-00-11-00-34-02-00-1A
00-24-02-00-11-00-34-02-00-1A-00-24-02-00-11-00
34-02-00-1A-00-24-02-00-11-00-06-02-00-01-00-36
04-00-1F-00-34-02-00-1A-00-24-02-00-11-00-34-02
00-1A-00-3E-02-00-1F-00-24-02-00-11-00-06-02-00
01-00-36-04-00-1F-00-34-02-00-1A-00-24-02-00-11
00-34-02-00-1A-00-24-02-00-11-00-06-02-00-01-00
36-04-00-1F-00-34-02-00-1A-00-24-02-00-11-00-34
02-00-1A-00-24-02-00-11-00-06-02-00-01-00-36-04
00-1F-00-34-02-00-1A-00-24-02-00-11-00-34-02-00
1A-00-24-02-00-11-00-06-02-00-01-00-36-04-00-1F
00-34-02-00-1A-00-24-02-00-11-00-34-02-00-1A-00
24-02-00-11-00-01-0E-75
and the new, broken one contains 386 bytes:
01-00-00-19-80-D8-07-22-00-1D-10-00-06-02-24-06
00-51-00-5D-18-00-25-00-4B-02-00-20-00-35-04-00
1F-00-3A-0A-00-16-00-00-81-6A-00-36-04-08-1F-00
34-02-00-1A-00-24-02-00-11-00-34-02-00-1A-00-24
02-00-11-00-06-02-00-05-00-36-04-00-1F-00-34-02
00-1A-00-24-02-00-11-00-34-02-00-1A-00-24-02-00
11-00-06-02-00-05-00-36-04-00-1F-00-34-02-00-1A
00-24-02-00-11-00-34-02-00-1A-00-24-02-00-11-00
06-02-00-05-00-36-04-00-1F-00-34-02-00-1A-00-24
02-00-11-00-34-02-00-1A-00-24-02-00-11-00-06-02
00-05-00-36-04-00-1F-00-34-02-00-1A-00-24-02-00
11-00-34-02-00-1A-00-24-02-00-11-00-34-02-00-1A
00-24-02-00-11-00-34-02-00-1A-00-24-02-00-11-00
34-02-00-1A-00-24-02-00-11-00-06-02-00-05-00-36
04-00-1F-00-34-02-00-1A-00-24-02-00-11-00-34-02
00-1A-00-3E-02-00-1F-00-24-02-00-11-00-06-02-00
05-00-36-04-00-1F-00-34-02-00-1A-00-24-02-00-11
00-34-02-00-1A-00-24-02-00-11-00-06-02-00-05-00
36-04-00-1F-00-34-02-00-1A-00-24-02-00-11-00-34
02-00-1A-00-24-02-00-11-00-06-02-00-05-00-36-04
00-1F-00-34-02-00-1A-00-24-02-00-11-00-34-02-00
1A-00-24-02-00-11-00-06-02-00-05-00-36-04-00-1F
00-34-02-00-1A-00-24-02-00-11-00-34-02-00-1A-00
24-02-00-11-00-01-0E-75-FF-FF-F8-49-00-00-87-B9
00-00
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.