Bug 454925 - Stracktraces contain addresses that are off by one, except frame 0
Summary: Stracktraces contain addresses that are off by one, except frame 0
Status: REPORTED
Alias: None
Product: valgrind
Classification: Developer tools
Component: general (show other bugs)
Version: unspecified
Platform: Debian stable Linux
: NOR minor
Target Milestone: ---
Assignee: Julian Seward
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2022-06-06 08:44 UTC by Bernhard Übelacker
Modified: 2022-11-10 09:20 UTC (History)
1 user (show)

See Also:
Latest Commit:
Version Fixed In:
Sentry Crash Report:


Attachments
Attempt-to-fix-EIP-pointer-in-stacktrace.patch (4.71 KB, application/octet-stream)
2022-06-06 08:44 UTC, Bernhard Übelacker
Details

Note You need to log in before you can comment on or make changes to this bug.
Description Bernhard Übelacker 2022-06-06 08:44:44 UTC
Created attachment 149505 [details]
Attempt-to-fix-EIP-pointer-in-stacktrace.patch

The addresses in stacktraces shown by valgrind are off by one, except for frame 0.
This seems to be explained in this commit: 
https://sourceware.org/git/?p=valgrind.git;a=patch;f=coregrind/m_stacktrace.c;h=efaaa0b74a695a68ef5e758102d3fe3920e121fd

So valgrind is decrementing the address by one to get into the call instruction.
But when showing the stacktrace this decremention gets not corrected later.
Below example shows the same process, one with the valgrind stacktrace and one with the gdb stacktrace.
A disassemble shows valgrind's address in the last byte of the call instruction, while
gdb shows the next byte, the return address of the call instruction.

$ valgrind --vgdb=yes --vgdb-error=0 rc
==4357== Invalid free() / delete / delete[] / realloc()
==4357==    at 0x4840EB7: free (vg_replace_malloc.c:872)
==4357==    by 0x1134BF: ??? (in /usr/bin/rc.byron)
==4357==    by 0x118B7C: ??? (in /usr/bin/rc.byron)
==4357==    by 0x118473: ??? (in /usr/bin/rc.byron)
==4357==    by 0x486F6E5: rl_completion_matches (in /usr/lib/i386-linux-gnu/libreadline.so.8.1)
==4357==    by 0x118760: ??? (in /usr/bin/rc.byron)
...

$ gdb $(which rc)
(gdb) target remote | /usr/bin/vgdb --pid=4357
(gdb) cont
(gdb) bt
#0  0x04840eb7 in _vgr10050ZU_VgSoSynsomalloc_free (p=0x4b2e758) at m_replacemalloc/vg_replace_malloc.c:872
#1  0x001134c0 in ?? ()
#2  0x00118b7d in ?? ()
#3  0x00118474 in ?? ()
#4  0x0486f6e6 in rl_completion_matches () from /lib/i386-linux-gnu/libreadline.so.8
#5  0x00118761 in ?? ()
...
Dump of assembler code from 0x4840eb5 to 0x4840ebd:
   0x04840eb5 <_vgr10050ZU_VgSoSynsomalloc_free+101>:   87 db   xchg   %ebx,%ebx
   0x04840eb7 <_vgr10050ZU_VgSoSynsomalloc_free+103>:   89 55 e0        mov    %edx,-0x20(%ebp)
   0x04840eba <_vgr10050ZU_VgSoSynsomalloc_free+106>:   8b 45 e0        mov    -0x20(%ebp),%eax
End of assembler dump.
...
(gdb) disassemble /r 0x001134ba,0x001134c6
Dump of assembler code from 0x1134ba to 0x1134c6:
   0x001134ba:  50      push   %eax
   0x001134bb:  e8 c0 6b ff ff  call   0x10a080 <free@plt>
   0x001134c0:  83 c4 10        add    $0x10,%esp
   0x001134c3:  83 c4 08        add    $0x8,%esp
End of assembler dump.


Attached patch is an attempt to correct just the output of the stacktrace in `VG_(describe_IP)`
while leaving the internal used address unchanged.


SOFTWARE/OS VERSIONS
Linux: 
valgrind 1:3.16.1-1 amd64 (Bullseye)
valgrind 1:3.18.1-1 i386  (Bookworm)