2

valgrindから出力を受け取ったところですが、よくわかりません。

==20290== Invalid read of size 1
==20290==    at 0x8C1D678: ???
==20290==    by 0x5D74C47: ???
==20290==  Address 0xee818c7d is not stack'd, malloc'd or (recently) free'd
==20290== 
==20290== 
==20290== Process terminating with default action of signal 11 (SIGSEGV)
==20290==  Access not within mapped region at address 0xEE818C7D
==20290==    at 0x8C1D678: ???
==20290==    by 0x5D74C47: ???
==20290==  If you believe this happened as a result of a stack
==20290==  overflow in your program's main thread (unlikely but
==20290==  possible), you can try to increase the size of the
==20290==  main thread stack using the --main-stacksize= flag.
==20290==  The main thread stack size used in this run was 8388608.
==20290==

特に、これらの疑問符に混乱しています。通常、この場所で得られるのは、valgrindが検出したエラーの場所です。私は以前にvalgrindを使用しましたが、すべての出力はマニュアルに記載されているとおりでした。私はこのvalgrindコマンドを使用しました：

valgrind --tool=memcheck --leak-check=full --leak-resolution=high --num-callers=20 --track-origins=yes

プログラム自体がセグメンテーション違反を叫びます。今回、valgrindはメモリリークの場所を教えてくれませんが、デバッグから、セグメンテーション違反が発生する場所を特定しました。残念ながら、これはIntel ODEソルバーライブラリ（dodesol）のODEソルバー関数内にあり、アクセスできません。この関数に渡すすべてのパラメーターを何度も注意深くチェックしましたが、問題はないようです（少なくとも、以前のマニュアルや例のパラメーターに対応しています）。

4

2 に答える 2

3

ほぼ確実に、???Valgrindが問題のアドレスの近くにシンボルを見つけることができなかったことを意味します。コードがない場所でコードを実行しているのではないかと思います。これは、スタック上のリターンアドレスを上書きした結果である可能性があります。たとえば、バッファオーバーランの結果である可能性があります（ただし、他のポインタエラーがトリガーされる可能性があります）Valgrindは、動的に割り当てられたメモリの問題に非常に優れていますが、スタック上の配列がどこで終了するかを常に判断できるとは限らないため、ローカル変数を使用するのは困難です。

于 2013-03-08T14:40:01.677 に答える
1

この結果が得られるシナリオの1つは、削除されたバイナリ/ライブラリでValgrindを実行していて、ローカルシンボル（静的関数など）内でエラーが見つかった場合です。

すべてのローカルシンボルに関する情報がまだ含まれている、ストリップされていないバージョンのバイナリ/ライブラリを使用すると、Valgrind出力にソースファイルと行番号が表示されます。

于 2013-03-08T16:06:33.697 に答える