Problem adding sequence points to a method with portable PDB #840
Comments
Zastai
changed the title
|
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 I'll prepare a PR. |
Zastai
added a commit
to Zastai/cecil
that referenced
this issue
Jun 10, 2022
This is required by the Portable PDB specification, and the sequence point collection in `MethodDebugInfo` does not guarantee it. This also tweaks the writing of hidden sequence points to use two writes of 0 as compressed unsigned integer, instead of a single write of 0 as a plain short, to more closely match the specification. Fixes jbevain#840.
This was referenced Jun 10, 2022
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
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.
The text was updated successfully, but these errors were encountered: