"gdb“和”val差制“以不同的方式执行二进制？

Question

我的程序出了堆内存损坏的错误。

osboxes@osboxes:/mnt/hgfs/VM_Shared/ISSUES/_[02]$ ./shuf /dev/null
*** Error in `./shuf': corrupted double-linked list: 0xb7f01ac0 ***

在仅使用gdb进行调试时，我遇到了valgrind。(多亏了这里)

还有.我用valgrind找到了日志。

(很抱歉，日志太长了，我想在询问之前把它缩写一下，但我担心我可能会遗漏一些分析所需的信息。)

osboxes@osboxes:~/Desktop/VM_Shared/ISSUES/_[02]$ valgrind --run-libc-freeres=no ./shuf /dev/null
==23373== Command: ./shuf /dev/null
==23373== 
==23373== Invalid read of size 4
==23373==    at 0x40B7859: _IO_file_close_it@@GLIBC_2.1 (fileops.c:178)
==23373==    by 0x40B4AE6: freopen64 (freopen64.c:49)
==23373==    by 0x804EECF: ??? (shuf.s:22773)
==23373==  Address 0x20 is not stack'd, malloc'd or (recently) free'd
==23373== 
==23373== Process terminating with default action of signal 11 (SIGSEGV)
==23373==  Access not within mapped region at address 0x20
==23373==    at 0x40B7859: _IO_file_close_it@@GLIBC_2.1 (fileops.c:178)
==23373==    by 0x40B4AE6: freopen64 (freopen64.c:49)
==23373==    by 0x804EECF: ??? (shuf.s:22773)
==23373==  If you believe this happened as a result of a stack
==23373==  overflow in your program's main thread (unlikely but
==23373==  possible), you can try to increase the size of the
==23373==  main thread stack using the --main-stacksize= flag.
==23373==  The main thread stack size used in this run was 8388608.
==23373== 
==23373== HEAP SUMMARY:
==23373==     in use at exit: 2,020 bytes in 31 blocks
==23373==   total heap usage: 32 allocs, 1 frees, 2,025 bytes allocated
==23373== 
==23373== LEAK SUMMARY:
==23373==    definitely lost: 0 bytes in 0 blocks
==23373==    indirectly lost: 0 bytes in 0 blocks
==23373==      possibly lost: 0 bytes in 0 blocks
==23373==    still reachable: 2,020 bytes in 31 blocks
==23373==         suppressed: 0 bytes in 0 blocks
==23373== Rerun with --leak-check=full to see details of leaked memory
==23373== 
==23373== For counts of detected and suppressed errors, rerun with: -v
==23373== ERROR SUMMARY: 1 errors from 1 contexts (suppressed: 0 from 0)
Segmentation fault (core dumped)

问题:

valgrind说无效阅读发生在178 line in fileopc.c。

但是，我发现这个程序从来没有在178 line in fileopc.c上被gdb调试过！

控制流以不同的方式进行，如下所示。

pwndbg> 
176 in fileops.c
────────────────────────────[ DISASM ]────────────────────────────
   0xb7e7184f <_IO_file_close_it+63>     mov    edx, dword ptr [ebx + 0x68]
   0xb7e71852 <_IO_file_close_it+66>     test   edx, edx
 > 0xb7e71854 <_IO_file_close_it+68>   ✔ jle    _IO_file_close_it+151 <0xb7e718a7>
    ↓
   0xb7e718a7 <_IO_file_close_it+151>    push   0
   0xb7e718a9 <_IO_file_close_it+153>    push   0
   0xb7e718ab <_IO_file_close_it+155>    push   0


pwndbg> 
185 in fileops.c
────────────────────────────[ DISASM ]────────────────────────────
   0xb7e7184f <_IO_file_close_it+63>     mov    edx, dword ptr [ebx + 0x68]
   0xb7e71852 <_IO_file_close_it+66>     test   edx, edx
   0xb7e71854 <_IO_file_close_it+68>     jle    _IO_file_close_it+151 <0xb7e718a7>
    ↓
 > 0xb7e718a7 <_IO_file_close_it+151>    push   0
   0xb7e718a9 <_IO_file_close_it+153>    push   0
   0xb7e718ab <_IO_file_close_it+155>    push   0

问题(续) :

正如您所看到的，控制流没有到达178 line in fileopc.c，valgrind说在那里嵌入了bug。

相反，控制流只是直接从176 in fileops.c跳到185 in fileops.c。

问题:

这里面发生了什么？为什么valgrind和gdb之间的控制流不同

这是因为这两种工具在生成受检查的程序时使用不同的方式吗？

Answer 1

这里面发生了什么？

来自英勇常见问题

程序在瓦莱尔上运行正常，但退出时会产生一堆涉及__libc_freeres的错误，然后用分段错误死掉。 当程序退出时，Valgrind在glibc中运行过程__libc_freeres。这是内存调试器的挂钩，因此他们可以要求glibc释放它使用过的任何内存。这样做是必要的，以确保瓦兰没有错误地报告空间泄漏在glibc中。 问题是，在较早的glibc版本中运行__libc_freeres会导致此崩溃。 为1.1.X和更高版本的Valgrind提供解决办法:使用--=no选项。然后，您可能会得到有关glibc分配的空间泄漏报告(请不要向glibc人员报告这些报告，因为它们不是真正的泄漏)，但至少程序运行。

请注意，虽然上面的文本谈到了较旧的GLIBCs，但这也可能发生在破坏GLIBC内部状态的程序中，这显然是这里的情况。

为什么控制流和gdb是不同的

GDB不调用__libc_freeres，val差尔调用。(还有许多其他细微的差异，但这是最有可能解释的观察到的坠机。)