C++堆损坏和valgrind

C++ heap corruption and valgrind

本文关键字：valgrind 损坏 C++      更新时间：2023-10-16

我在Solaris/Linux平台上都有一个核心，我没有发现问题。在linux平台上，我有以下核心：

(gdb) where
#0  0x001aa81b in do_lookup_x () from /lib/ld-linux.so.2
#1  0x001ab0da in _dl_lookup_symbol_x () from /lib/ld-linux.so.2
#2  0x001afa05 in _dl_fixup () from /lib/ld-linux.so.2
#3  0x001b5c90 in _dl_runtime_resolve () from /lib/ld-linux.so.2
#4  0x00275e4c in __gxx_personality_v0 () from /opt/gnatpro/lib/libstdc++.so.6
#5  0x00645cfe in _Unwind_RaiseException_Phase2 (exc=0x2a7b10, context=0xffd58434) at ../../../src/libgcc/../gcc/unwind.inc:67
#6  0x00646082 in _Unwind_RaiseException (exc=0x2a7b10) at ../../../src/libgcc/../gcc/unwind.inc:136
#7  0x0027628d in __cxa_throw () from /opt/gnatpro/lib/libstdc++.so.6
#8  0x00276e4f in operator new(unsigned int) () from /opt/gnatpro/lib/libstdc++.so.6
#9  0x08053737 in Receptor::receive (this=0x93c12d8, msj=...) at Receptor.cc:477
#10 0x08099666 in EventProcessor::run (this=0xffd75580) at EventProcessor.cc:437
#11 0x0809747d in SEventProcessor::run (this=0xffd75580) at SEventProcessor.cc:80
#12 0x08065564 in main (argc=1, argv=0xffd76734) at my_project.cc:20

在Solaris平台上，我有另一个核心：

$ pstack core.ultimo
core 'core.ultimo' of 9220:     my_project_sun
-----------------  lwp# 1 / thread# 1  --------------------
 0006fa28 __1cDstdGvector4CpnMDistribuidor_n0AJallocator4C2___Dend6kM_pk2_ (1010144, 1ce84, ffbd0df8, ffb7a18c, fffffff8, ffbedc7c) + 30
 0005d580 __1cDstdGvector4CpnMDistribuidor_n0AJallocator4C2___Esize6kM_I_ (1010144, 219, 1ce84, ffffffff, fffffff8, ffbedc7c) + 30
 0005ab14 __1cTReceptorHreceive6MrnKMensaje__v_ (33e630, ffbede70, ffffffff, 33e634, 33e68c, 0) + 1d4
 0015df78 __1cREventProcessorDrun6M_v_ (ffbede18, 33e630, dcc, 1, 33e730, 6e) + 350
 00159a50 __1cWSEventProcessorDrun6M_v_ (da08000, 2302f7, 111de0c, 159980, ff1fa07c, cc) + 48
 000b6acc main     (1, ffbeef74, ffbeef7c, 250000, 0, 0) + 16c
 00045e10 _start   (0, 0, 0, 0, 0, 0) + 108
-----------------  lwp# 2 / thread# 2  --------------------

这段代码是：

...
msj2.tipo(UPDATE);
for(i = 0; i < distr.size(); ++i)
{
    distr[i]->insert(new Mensaje(msj2)); **--> Receptor.cc:477**
}
...

这个核心是随机发生的，有时这个过程会持续数周。核心尺寸为4291407872 B.

我正在运行valgrind来查看堆是否已损坏，但到目前为止，我还没有遇到"无效读取"、"无效写入"等问题。。。此外，当我运行valgrind时，我发现了两次以下信息：

==19002== Syscall param semctl(arg) points to uninitialised byte(s)

我已经检测到了代码行，但这些错误会导致核心吗？我想我以前在valgrind中看到过这些错误，它们并没有那么重要，还有那些写着"无效读/写"的错误。

如果你对如何解决这个问题有任何想法，我们将不胜感激。

核心大小是线索。最大的32位无符号数字是4294967295。你的核心非常接近这一点，这表明进程内存不足。最可能的原因是内存泄漏。

请参阅我最近的文章"C/C++中的内存泄漏"

Valgrind会在Linux上为您找到问题。为此，您必须使用--leak-check选项来启动它。当进程正常退出时，它将检查是否存在泄漏，因此您需要一种关闭进程的方法。

在Solaris上使用dbx的Dtrace也可能工作。

此外，当我在经营valgrind时，我发现了两次以下情况消息：

==19002== Syscall param semctl(arg) points to uninitialised byte(s)

我已经检测到了代码行，但这些错误会导致核心？

是的，这可能会导致SIGSEGV，因为它很可能是未定义的行为。（在没有看到实际代码的情况下，我不会说这肯定是未定义的行为，但很可能是。）这样做不太可能导致SIGSEGV，但你看到的间歇性故障并不经常发生。所以你确实需要解决这个问题。

除了valgrind之外，在Solaris上，还可以使用libumem和watchmalloc来检查管理堆内存的问题。请参阅umem_debug和watchmalloc的手册页以开始操作。

要在Solaris上使用dbx，您需要安装SolarisStudio（它是免费的）。SolarisStudio还提供了一种使用dbx的运行时内存检查的方法，而无需直接调用dbx调试器。请参阅bcheck的手册页。bcheck手册页将位于SolarisStudio安装目录树的man目录中。

如果是内存泄漏，您应该能够看到进程地址空间随着时间的推移而增长。

相关文章：