C++堆損壞和valgrind

我在Solaris/Linux平臺上都有一個核心，我沒有看到問題。在Linux平臺上，我有以下核心：C++堆損壞和valgrind

(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的這些錯誤，他們並不重要，而且那些說「無效讀/寫」的錯誤。

如果您有任何想法如何解決這個問題，將不勝感激。

來源

2016-08-04 mab

看起來你的進程是32位，核心是4GB左右。嘗試捕捉'std :: bad_alloc'。 – rustyx

核心大小是線索。最大的32位無符號數是4,294,967,295。你的核心與這個過程非常接近，表明這個過程沒有記憶。最可能的原因是內存泄漏。

見我最近的文章Memory Leaks in C/C++

Valgrind的會發現這個問題你在Linux上。你必須從--leak-check選項開始。當流程正常退出時它將檢查泄漏情況，因此您需要一種方法來關閉流程。

在Solaris上使用dbx的Dtrace也可能有效。

來源

2016-08-04 12:26:05

而且，當我運行的valgrind我發現兩次以下消息：
==19002== Syscall param semctl(arg) points to uninitialised byte(s) 
，我已經檢測到的代碼行，但可以將這些錯誤導致核心？

是的，這可能導致SIGSEGV，因爲它很可能是未定義的行爲。（我不打算說沒有看到實際的代碼肯定是未定義的行爲 - 但它可能是）。這不是可能這樣做可能會導致SIGSEGV，但然後再次發生間歇性故障，你看到不經常發生。所以你確實需要解決這個問題。

除了valgrind，在Solaris上，您還可以使用libumem和watchmalloc來檢查管理堆內存的問題。請參閱手冊頁umem_debug和watchmalloc以開始使用。

要在Solaris上使用dbx，您需要安裝Solaris Studio（它是免費的）。 Solaris Studio還提供了一種使用dbx的運行時內存檢查的方法，無需直接調用dbx調試器。請參閱手冊頁bcheck。 bcheck手冊頁將位於Solaris Studio安裝目錄樹的man目錄中。

如果是內存泄漏，您應該能夠看到進程地址空間隨着時間的推移而增長。

來源

2016-08-04 14:27:12

C++堆損壞和valgrind

回答

相關問題