the Same dmp get diffrent offset

[Alcestis Miller]

i use minidump_processor to read minidump process_minidump data,i got result just like this

 1  AstrolabeDemo.exe + 0xddd0
     rsp = 0x000000611e0fa220    rip = 0x00007ff6227bddd1
    Found by: stack scanning

but,when i use
https://github.com/mozilla-services/minidump-stackwalk
i got another resut

AstrolabeDemo.exe + 0xddd1
    rbp = 0x000000611e0ff680   rsp = 0x000000611e0fa220
    rip = 0x00007ff6227bddd1
    Found by: stack scanning

i don't know two result which one is right？

[Gabriele Svelto]

The frame was found via stack-scanning which uses slightly different heuristics between the two. There's no guarantee that either is right. The only way to verify is to walk the stack again with CFI information.

[Ted Mielczarek]

I think this may also be due to some minor difference in how the Rust crate treats return addresses. Breakpad (the underlying C++ library used in the mozilla-services code) adds an additional +1 to return addresses for arcane reasons.

[Alcestis Miller]

I think this may also be due to some minor difference in how the Rust crate treats return addresses. Breakpad (the underlying C++ library used in the mozilla-services code) adds an additional +1 to return addresses for arcane reasons.

this demo is the same

minidump process

 0  AstrolabeDemo.exe + 0x33d2
     rax = 0x0000000000000000    rdx = 0x00007ff6227bdedf
     rcx = 0x000000611e0ff680    rbx = 0x0000000000000013
     rsi = 0x000000611e0fa390    rdi = 0x0000000000000000
     rbp = 0x000000611e0ff680    rsp = 0x000000611e0fa218
      r8 = 0x00007ff6227b0000     r9 = 0x000000611e0fa390
     r10 = 0x0000000000000000    r11 = 0x000000611e0fa320
     r12 = 0x000000611e0ff680    r13 = 0x000000611e0fa390
     r14 = 0x0000000000000009    r15 = 0x00000186d39f03d0
     rip = 0x00007ff6227b33d2

mozilla-services
···
0 AstrolabeDemo.exe + 0x33d2
rax = 0x0000000000000000 rdx = 0x00007ff6227bdedf
rcx = 0x000000611e0ff680 rbx = 0x0000000000000013
rsi = 0x000000611e0fa390 rdi = 0x0000000000000000
rbp = 0x000000611e0ff680 rsp = 0x000000611e0fa218
r8 = 0x00007ff6227b0000 r9 = 0x000000611e0fa390
r10 = 0x0000000000000000 r11 = 0x000000611e0fa320
r12 = 0x000000611e0ff680 r13 = 0x000000611e0fa390
r14 = 0x0000000000000009 r15 = 0x00000186d39f03d0
rip = 0x00007ff6227b33d2
Found by: given as instruction pointer in context
···
so i think additional +1 only apply to index zero

[Ted Mielczarek]

Right, frame 0 is directly from the CPU context in the minidump, so there's no addition involved there. In your original comment you can see that both implementations have the same value for rip, it's just the value used for symbolicating the function that's offset.

[Aria Beingessner]

I believe you are observing the difference between instruction and resume_address. We print a value based on instruction while breakpad I guess uses a value based on resume_address.

On x86/x64 the difference between these two values is that instruction = resume_address - 1, because that will always be "in" the instruction that did the function call for the purposes of symbolication. See the linked docs for the accursed situations where resume_address can be Wrong even though instruction is Right.