C++ヒープの破損とvalgrind

Question

私はSolaris/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プラットフォームの場合：Linuxプラットフォームで が、私は次のコアを持っている

$ 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** 

} 
... 

このコアはランダムに発生し、プロセスが数週間実行されることがあります。 コアのサイズはまた、ときB.

私は、ヒープが破損しているが、今では、私は「無効読み取り」などの問題が発生していないかどうかを確認するためにvalgrindのを実行しています、「無効な書き込み」... 4291407872です私は二回、次のメッセージを発見したvalgrindの走っていた：

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

を、私はコードの行を検出したが、これらのエラーは、コアにつながる可能性がありますか？私は前にvalgrindでこれらのエラーを見たことがあり、重要ではなく、「無効な読み取り/書き込み」と言うものもなかったと思います。

この問題を解決する方法があれば、非常に感謝しています。

Answer 1

コアサイズはヒントです。最大の32ビット符号なし数は4,294,967,295です。あなたのコアは、プロセスがメモリ不足であることを示すものにかなり近いです。最も可能性の高い原因はメモリリークです。

はMemory Leaks in C/C++

Valgrindのは、Linux上のあなたのための問題を見つけるだろう私の最近の記事を参照してください。このためには--leak-checkオプションで起動する必要があります。プロセスが正常に終了したときにリークがないかどうかチェックするので、プロセスをシャットダウンする方法が必要になります。

Solaris上でdbxを使用したDtraceもうまく機能します。私はvalgrindのを実行していたとき

また

Answer 2

は、私は二回、次の のメッセージを発見した：

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

を、私はコードの行を検出したが、これらのエラーは コアにつながる可能性がありますか？

はい、それはおそらく未定義の動作であるため、SIGSEGVになる可能性があります。 （実際のコードを見ることなく、明確に未定義の動作であるとは言いませんが、おそらくそうです）。そうでないとSIGSEGVが発生する可能性がありますが、断続的なエラーは表示されませんすべてのことが頻繁に起こります。だからあなたはその問題を解決する必要があります。

valgrindに加えて、libumemとwatchmallocを使用して、ヒープメモリの管理に関する問題を確認することもできます。開始するには、umem_debugとwatchmallocのマニュアルページを参照してください。

Solarisでdbxを使用するには、Solaris Studioをインストールする必要があります（無料です）。 Solaris Studioでは、dbxデバッガを直接呼び出すことなく、ランタイムメモリチェックdbxを使用する方法も提供されています。 bcheckのmanページを参照してください。 bcheckのマニュアルページは、Solaris Studioインストールディレクトリツリーのmanディレクトリにあります。

メモリリークの場合は、プロセスアドレススペースが時間の経過とともに大きくなることがわかります。