Ran into this while implementing STACK WIN unwinding in rust-minidump.
Sometimes we get STACK WIN directives where each line has an accurate starting point, but the length just covers the entire function(?), like so:
addr: 0, len: 10
addr: 1, len: 9
addr: 4, len: 6
In this case, the next instruction is the one that really defines the length of the previous one. So we need to fixup the lengths like so:
addr: 0, len: 1
addr: 1, len: 2
addr: 4, len: 6
Now that I know it's a thing and have a workaround it's not a big deal, but presumably this is "wrong" for dump_syms to generate.
I'm still dropping a few more entries with weirder intersecting ranges that this heuristic doesn't work for, but I haven't yet inspected what they are since they haven't caused me trouble. If you run this branch of rust-minidump on e.g. this minidump with --verbose=warn, it will report all the STACK WIN entries it threw out as a result.
Ran into this while implementing STACK WIN unwinding in rust-minidump.
Sometimes we get STACK WIN directives where each line has an accurate starting point, but the length just covers the entire function(?), like so:
In this case, the next instruction is the one that really defines the length of the previous one. So we need to fixup the lengths like so:
Now that I know it's a thing and have a workaround it's not a big deal, but presumably this is "wrong" for dump_syms to generate.
I'm still dropping a few more entries with weirder intersecting ranges that this heuristic doesn't work for, but I haven't yet inspected what they are since they haven't caused me trouble. If you run this branch of rust-minidump on e.g. this minidump with
--verbose=warn, it will report all theSTACK WINentries it threw out as a result.