2016-08-05 6 views
-1

私が職場で使用しているアプリケーションで奇妙で面倒な問題が発生しています。アプリケーションはC++で書かれており、アプリケーションが終了すると(メイン関数の戻り値またはexitが呼び出される)、セグメンテーション違反でクラッシュします。セグメンテーション違反は、basic_stringクラスのデストラクタでdouble-freeingポインタが原因であると考えられます。私はソースコードを追加することはできませんが、アプリケーションは非常にシンプルで、自分のコードに直接ポインタを使用しているわけではありません。アプリは単にライブラリから関数を呼び出すだけです。アプリケーションは両方の共有および静的ライブラリにリンクされているSegFault on application exit

==5402== Invalid read of size 4 
==5402== at 0x549F05F: std::basic_string<char, std::char_traits<char>, std::allocator<char> >::~basic_string() (atomicity.h:49) 
==5402== by 0x41D1BA4: ??? (in ../Functions.so) 
==5402== by 0x436D873: ??? (in ../Functions.so) 
==5402== by 0x967674: _dl_fini (in /lib/ld-2.12.so) 
==5402== by 0x9A7EAE: exit (in /lib/libc-2.12.so) 
==5402== by 0x810F8C2: main (Checker.C:146) 
==5402== Address 0x55ec808 is 8 bytes inside a block of size 15 free'd 
==5402== at 0x4007895: operator delete(void*) (vg_replace_malloc.c:480) 
==5402== by 0x549EF67: std::string::_Rep::_M_destroy(std::allocator<char> const&) (new_allocator.h:110) 
==5402== by 0x810F8C2: main (Checker.C:146) 
==5402== 
==5402== Invalid free()/delete/delete[]/realloc() 
==5402== at 0x4007895: operator delete(void*) (vg_replace_malloc.c:480) 
==5402== by 0x549EF67: std::string::_Rep::_M_destroy(std::allocator<char> const&) (new_allocator.h:110) 
==5402== by 0x41D1BA4: ??? (in ..../Functions.so) 
==5402== by 0x436D873: ??? (in .../Functions.so) 
==5402== by 0x967674: _dl_fini (in /lib/ld-2.12.so) 
==5402== by 0x9A7EAE: exit (in /lib/libc-2.12.so) 
==5402== by 0x810F8C2: main (Checker.C:146) 
==5402== Address 0x55ec800 is 0 bytes inside a block of size 15 free'd 
==5402== at 0x4007895: operator delete(void*) (vg_replace_malloc.c:480) 
==5402== by 0x549EF67: std::string::_Rep::_M_destroy(std::allocator<char> const&) (new_allocator.h:110) 
==5402== by 0x810F8C2: main (Checker.C:146) 
==5402== 

Valgridは、次のような問題を識別します。 Function.soは、いくつかの静的コードを含む共有ライブラリです。この問題はリンクフェーズに関連しています。なぜなら、ライブラリが実行可能ファイルにリンクされている順番によっては、アプリケーションがクラッシュしない可能性があるからです。

私は本当にこの問題に取り組むのに苦労しています。そのような問題の根本原因になる可能性はありますか?どのようにこの問題を調査するために進むための提案?

+2

あなたは図書館のコードを見ることができますか?おそらく、いくつかの静的データには、バグのあるデストラクタまたはコンストラクタがあります。 –

+0

はい、私はlibを所有しています。私はそれを調べることができます –

答えて

1

この問題の根本原因は、コードのどこかにあるバグです。バグは何でもかまいません。ワイルドなポインタの逆参照、配列の終わりからの実行、または多数の他の多くの種類のバグ。 C++コードのバグは、アプリケーションがその時点ですぐにクラッシュすることを必ずしも意味するものではありません。アプリケーションは実行を続けることができますが、バグの結果として破損したメモリにアクセスしようとすると、後の時点でクラッシュします。

コードのどこかにバグがあり、アプリケーションが終了したときにこのクラッシュを引き起こすメモリ破損が発生する可能性があります。それを見つけて修正する必要があります。 C++へようこそ。

+0

私はバグを見つける過程で私を助けるために使用できる任意の提案、ツールですか? –

+0

'valgrind'は、この種のバグを見つけ出すのにとても良いことがよくあります。それはいつもうまくいくとは限りませんが、通常それらを見つけるでしょう。最高のツールは、常に自分の脳です。 –