我的程序出现堆内存损坏错误。
osboxes@osboxes:/mnt/hgfs/VM_Shared/ISSUES/_[02]$ ./shuf /dev/null
*** Error in `./shuf': corrupted double-linked list: 0xb7f01ac0 ***
在仅使用gdb进行调试时，我遇到了valgrind。 （感谢Here）
并且......我使用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之间有所不同？
是因为这两个工具在产生被检查程序时使用不同的方式吗？
这里发生了什么？
来自valgrind FAQ：
程序在Valgrind上运行正常，但在退出时产生一系列涉及__libc_freeres的错误，然后因分段错误而死亡。
程序退出时，Valgrind在glibc中运行__libc_freeres程序。这是内存调试器的一个钩子，所以他们可以让glibc释放它已经使用过的任何内存。这样做是为了确保Valgrind不会错误地报告glibc中的空间泄漏。
问题是在较旧的glibc版本中运行__libc_freeres会导致此崩溃。
1.1.X及更高版本的Valgrind的解决方法：使用--run-libc-freeres = no选项。然后你可以获得glibc分配的空间泄漏报告（请不要向glibc人报告这些，因为它们不是真正的泄漏），但至少程序运行。
请注意，虽然上面的文本讨论了旧的GLIBC，但这也可能发生在破坏GLIBC内部状态的程序中，这显然就是这里的情况。
为什么valgrind和gdb之间的控制流程不同
GDB没有打电话给__libc_freeres，Valgrind也是。 （还有许多其他微妙的差异，但这个是对观察到的崩溃最可能的解释。）