我正在编写一个客户端应用程序，它通过套接字与服务器应用程序通信。我目前正在遇到应用程序正常运行的奇怪行为，但之后我会在屏幕上抛出许多行，如下所示。
*** glibc detected *** ./sll_client: free(): invalid next size (fast): 0x0000000000787720 ***
======= Backtrace: =========
/lib/x86_64-linux-gnu/libc.so.6(+0x78a8f)[0x7f9e9cbb5a8f]
/lib/x86_64-linux-gnu/libc.so.6(cfree+0x73)[0x7f9e9cbb98e3]
/usr/lib/x86_64-linux-gnu/libstdc++.so.6(_ZNSsD1Ev+0x39)[0x7f9e9d409019]
======= Memory map: ========
7f9e9d893000-7f9e9d895000 rw-p 00021000 07:00 7473 /lib/x86_64-linux- gnu/ld-2.13.so
7fff68119000-7fff6813a000 rw-p 00000000 00:00 0 [stack]
7fff68167000-7fff68168000 r-xp 00000000 00:00 0 [vdso]
ffffffffff600000-ffffffffff601000 r-xp 00000000 00:00 0 [vsyscall]
Aborted
特定的“glibc”错误几乎每次都不同。
我已经通过Valgrind运行应用程序，几乎没有检测到内存泄漏。那里的那些似乎没有引起任何问题。有这个问题的一般原因吗？我可以发布一些代码，但它有超过三千行的C ++，这是三周来第一次出现这个问题。
答案 0 :(得分：4)
大小为4的无效写入几乎肯定是造成问题的原因。你正在踩踏你不拥有的内存，很可能只是在一个动态分配的内存区域之前或之后。
大小为4的无效读取也存在问题，但不会导致您获得的输出。不管怎样，修复它们。 ： - ）
内存错误可能是一个巨大的痛苦，因为它们的影响可能会在问题真正发生的地方显示出很长的路要走。这是Valgrind等工具的一部分。内存泄漏检测实际上是一个次要功能。
答案 1 :(得分：1)
您是否跟踪了valgrind日志中发生的Invalid read of size 4消息的根本原因？
那些无效的读取是您的问题的根本原因。