C++程序退出时出现内存错误
我正在编写一个客户端应用程序，通过套接字与服务器应用程序进行通信。我目前遇到奇怪的行为，应用程序正常运行，但随后我在屏幕上看到了许多类似以下内容的行。
*** 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++ 代码，这是三周以来第一次出现这个问题。
I am writing a client-side app that communicates to a server app through sockets. I'm currently experiencing weird behavior where the application finishes running properly, but then I get many lines like the following thrown on the screen afterwards.
*** 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
The specific "glibc" error is different nearly every time.
I've already run the application through Valgrind and there are almost no memory leaks detected. The ones that are there don't seem to cause any problems. Is there a general cause of this problem? I could post some code, but its over three thousand lines of C++ and this is the first time in three weeks that this problem has come up.
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（2）
大小 4 的无效写入几乎肯定是导致您的问题的原因。您正在踩踏不属于您的内存，很可能就在动态分配的内存区域之前或之后。
大小为 4 的无效读取也有问题，但不会导致您得到的输出。无论如何都要修复它们。 :-)
内存错误可能会带来巨大的痛苦，因为它们的影响可能与问题的真正根源相去甚远。这就是 Valgrind 等工具的用途之一。内存泄漏检测实际上是一个小功能。
The invalid writes of size 4 are almost certainly what's causing your problem. You're stomping on memory you don't own, most likely just before or just after a region of memory that's been dynamically allocated.
The invalid reads of size 4 are problematic too, but aren't causing the output you're getting. Fix them anyway though. :-)
Memory errors can be a huge pain because their effects can show up a long way from where the problem really is. That's part of what tools like Valgrind are for. Memory leak detection is actually a minor feature.
您是否跟踪了 valgrind 日志中不断出现的
Invalid read of size 4消息的根本原因？这些无效读取是问题的根本原因。
Have you tracked the root cause of
Invalid read of size 4message that keeps occurring in your valgrind logs??Those invalid reads are the root cause of your problem.