11

文字列に単純な代入をしようとしているときにクラッシュする (つまり、 * glibc が検出された * free(): 無効なポインター: 0x000000000070f0c0 *** をアサートする) アプリケーションのクラッシュをデバッグしようとしています。最適化レベルを -O2 に設定して、gcc 4.2.4 を使用して Linux システムでコンパイルしていることに注意してください。-O0 を指定すると、アプリケーションはクラッシュしなくなりました。

例えば

std::string abc;

abc = "testString";

しかし、次のようにコードを変更すると、クラッシュしなくなりました

std::string abc("testString");

それでまた頭をかいた！しかし、興味深いパターンは、クラッシュがアプリケーションの後半に移動し、別の文字列で再び発生したことです。文字列の代入でアプリケーションが継続的にクラッシュするのは奇妙だと思いました。典型的なクラッシュ バックトレースは次のようになります。

#0  0x00007f2c2663bfb5 in raise () from /lib64/libc.so.6
(gdb) bt
#0  0x00007f2c2663bfb5 in raise () from /lib64/libc.so.6
#1  0x00007f2c2663dbc3 in abort () from /lib64/libc.so.6
#2  0x00000000004d8cb7 in people_streamingserver_sighandler (signum=6) at src/peoplestreamingserver.cpp:487
#3  <signal handler called>
#4  0x00007f2c2663bfb5 in raise () from /lib64/libc.so.6
#5  0x00007f2c2663dbc3 in abort () from /lib64/libc.so.6
#6  0x00007f2c26680ce0 in ?? () from /lib64/libc.so.6
#7  0x00007f2c270ca7a0 in std::string::assign (this=0x7f2c21bc8d20, __str=<value optimized out>)
    at /home/bbazso/ThirdParty/sources/gcc-4.2.4/x86_64-pc-linux-gnu/libstdc++-v3/include/bits/basic_string.h:238
#8  0x00007f2c21bd874a in PEOPLESProtocol::GetStreamName (this=<value optimized out>,
    pRawPath=0x2342fd8 "rtmp://127.0.0.1/mp4:pop.mp4", lStreamName=@0x7f2c21bc8d20)
    at /opt/trx-HEAD/gcc/4.2.4/lib/gcc/x86_64-pc-linux-gnu/4.2.4/../../../../include/c++/4.2.4/bits/basic_string.h:491
#9  0x00007f2c21bd9daa in PEOPLESProtocol::SignalProtocolCreated (pProtocol=0x233a4e0, customParameters=@0x7f2c21bc8de0)
    at peoplestreamer/src/peoplesprotocol.cpp:240

これは非常に奇妙な動作だったので、アプリケーションをさらに調べて、この奇妙な動作を引き起こしている可能性のある何らかのメモリ破損 (ヒープまたはスタック) エラーが発生していないかどうかを確認しました。ptr の破損もチェックしましたが、手ぶらで出てきました。コードの目視検査に加えて、次のツールも試しました。

  • memcheck と exp-ptrcheck の両方を使用する Valgrind
  • 電気柵
  • libsafe
  • gcc で -fstack-protector-all でコンパイルしました
  • MALLOC_CHECK_ を 2 に設定してみました
  • コードを lint チェックと cppcheck (間違いをチェックするため) で実行しました。
  • そして、gdb を使用してコードをステップ実行しました

だから私はたくさんのものを試しましたが、それでも手ぶらで出てきました。したがって、この問題を引き起こしている可能性があるのは、リンカーの問題やライブラリの問題のようなものではないかと考えていました。make が -O2 でクラッシュしやすい std::string に関する既知の問題はありますか、それとも最適化レベルとは関係ありませんか? しかし、私の問題でこれまでに確認できる唯一のパターンは、常に文字列でクラッシュするように見えることです。そのため、この種の動作を引き起こしている問題を誰かが知っているかどうか疑問に思っていました.

どうもありがとう！

4

4 に答える 4

10

これは、バックトレースから抽出できるすべての情報を使用した最初の推測です。

ほとんどの場合、gccバージョン、リンカー、およびlibstdc ++を混合して一致させると、ホストマシンで異常な動作が発生します。

  1. libcはシステムのものです：/lib64/libc.so.6
  2. libstdc ++は「ThirdParty」ディレクトリにあります-これは疑わしいです、それはそれが別のターゲットで他の場所でコンパイルされるかもしれないと私に告げます-/home/bbazso/ThirdParty/sources/gcc-4.2.4/x86_64-pc-linux-gnu/libstdc++-v3/
  3. さらに別のlibstdc++ /opt：/opt/trx-HEAD/gcc/4.2.4/lib/gcc/x86_64-pc-linux-gnu/4.2.4/../../../../include/c++/4.2.4/bits/basic_string.h:491

さらに、GCCはそれ自体ではなくシステムのldを混合する可能性があり、これによりさらに奇妙なメモリマップの使用が発生する可能性があります。

于 2010-02-20T21:24:53.953 に答える
7

基本的な 2 行のプログラムでクラッシュを再現できますか?

#include <string>

int main()
{
    std::string abc;
    abc = "testString";
}

それがクラッシュした場合は、正確なコンパイル/リンク オプションを投稿してください。

そうでない場合は、コードの削減を開始します。バグがなくなるまで、一度に一握りの行を削除します。他の変更を加えてクラッシュを引き起こし、削除してクラッシュをなくすことができれば、問題を特定するのに役立ちます。

于 2010-02-20T21:18:05.030 に答える
0

あなたが言ったように、それは奇妙な振る舞いです。

正直に言うと、std::stringsで発生する可能性のあるバグを調べるのに時間を無駄にしていると思います。ストリングを上手に使用している限り、ストリングは完全に安全です。

とにかく、あなたが提供している情報で：まず、あなたはスレッドを使用していますか？スレッドの問題である可能性があります。次に、valgrindを使用してプログラムをチェックします。警告はまったくありませんか？

注：最も重要なvalgrindの警告は、無効な読み取りと無効な書き込みです。

PS：解説で述べたように、おそらくg++を使用してC++コードをコンパイルする必要があります;）

于 2010-02-20T21:29:21.677 に答える