DEBUG神器valgrindのmemcheck報告分析
memcheckはどうやって動くの?
-log-fileは出力レポートファイルを表し、相対パスまたは完全パスであってもよい-tool=memcheckメモリ検出はmemcheckであり、valgrindがツールセットであることを知っておく必要があります-leak-check=full完全検出–show-reachable=no reachable詳細はメモリ漏洩部分を参照してください.通常はnoです.また、yes-workaround-gcc 296-bugs=yesに変更することもできます.gccに対応するバグがある場合は、yesに設定します.そうしないと、エラーが発生し、最後に被検出プログラムとそのパラメータになります.
memcheckレポートどう思う?
まず意外な書き間違えをする
コードエラーはmalloc()をmalloc[]と書き、malloc関数ポインタの後ろのアドレスを取得したことに相当し、出力レポートはこのアドレスが位置していることを示す.textセグメント.
レポートの基本的なフォーマットは次のとおりです.
レポートの出力ドキュメント全体のフォーマットは、次のようにまとめられます.
一般的な異常レポート
メモリリーク
definitely lost:メモリは解放されず、ここにポインタはありません.漏れたに違いない.レポートに示されるスタックは、メモリが割り当てられたときの呼び出しスタックであり、メモリがどのビジネスロジックによって作成されたかを基本的に明確にすることができます.still reachable:メモリが解放されていないということですが、ポインタがあり、メモリが使用されているので、漏洩ではありません.(プログラムが終了しても動作する非同期システム呼び出し?)possibly lost:漏れがある可能性があり、一般的には2次ポインタ(ポインタのポインタ)など複雑な状況が追跡しにくい場合に発生します.suppressed:valgrindを使用するパラメータの一部が特定のライブラリをキャンセルしたエラーを統計し、ここにまとめられます.
いじょうほうしゅつ
free()/delete/delete[]/realloc()の4つのいずれかで、freeの不正な解放です.アドレスの相対関係を記述する際に、Address 0 x???という文を使用します.is {x} bytes {inside/before/after} a block of size {y} {alloc’d/free’d}
これは、解放されたアドレスとy長ブロックとの相対的な位置関係を表す.アドレスがブロックの前にある場合はbefore,ブロック内にある場合はinside,ブロックの後にafterを用いる.最後のalloc’dは、このy長のブロックが有効な状態にあることを表し、その割り当て時のスタックは以下の通りである.free’dはy長ブロックが削除されたことを表し、その削除時のスタックは以下の通りである.
従って、上記の報告は、アドレス0 x 41 f 23 a 0が長さ1024の有効ブロック内+888に位置し、その割り当て時の呼び出しスタックは以下のように解釈される.
不正な読み書き
1つのメモリ領域の使用が割り当てられた時間を超えると、Invalid write/readがトリガーされ、長さが通知されます.この例ではuint 64_tは8バイト長で,アクセスは4バイトを超えた.bigBuff+1020をbigBuff-20に変更すると、Address xxx is 20 bytes before a block of...
もう一つ興味深い現象はuint 64_tの不正アクセスは4バイト長の不正アクセスのレポートを2回生成しますが、これは何を説明していますか?
不一致の解放
Mismatched free()/delete/delete[]レポートは、mallocの割り当て後にdeleteを使用してもdelete[]を使用しても、new[]を使用しても不注意にdeleteを使用しても取得され、レポート主体の内容はほぼ一致します.
初期値の使用
上記の例ではint unusedは値を付けずに使用され、このような問題は通常致命的ではないが、排除する必要があるというUse of uninitialised value of size 4の報告が得られた.
興味深いことに、スタックの最後のレイヤに初めて(below main)が現れ、main関数以外でコードが実行されていることを示しています.スレッドから来ているわけではありません.私はまだこの現象を明確に説明できませんが、次のテストをしました.
静的構造と解放
静的クラスの構造と解放はmainの外にあるので,(below main)の文字が現れ,スタックの関数名もこの2つのプロセスをよく確認した.ここでもう一つの問題を連想したのは,静的構造の順序が必ずしも予想通りではなく,静的オブジェクト間に依存関係がないことを強く提案することである.
クラッシュ
memcheckがあなたのプログラムを実行している間にクラッシュに遭遇した場合、それは依然としていくつかの役に立つ情報を提供することができます.
次に、クラッシュ時に各スレッドが置かれているスタックとスレッドの実行状態を順にレポートします.
では,実行中のスレッドは疑いが最も大きく,スタック情報を抽出してさらに解析することができる.
valgrind --log-file=valgrind.log --tool=memcheck --leak-check=full --show-reachable=no --workaround-gcc296-bugs=yes ./mcsample arg1 arg2-log-fileは出力レポートファイルを表し、相対パスまたは完全パスであってもよい-tool=memcheckメモリ検出はmemcheckであり、valgrindがツールセットであることを知っておく必要があります-leak-check=full完全検出–show-reachable=no reachable詳細はメモリ漏洩部分を参照してください.通常はnoです.また、yes-workaround-gcc 296-bugs=yesに変更することもできます.gccに対応するバグがある場合は、yesに設定します.そうしないと、エラーが発生し、最後に被検出プログラムとそのパラメータになります.
memcheckレポートどう思う?
まず意外な書き間違えをする
int main(int argc, char *argv[])
{
char* bigBuff = (char*)malloc[1024];
free(bigBuff);
}==3498== Invalid free() / delete / delete[] / realloc()
==3498== at 0x402B06C: free (in /usr/lib/valgrind/vgpreload_memcheck-x86-linux.so)
==3498== by 0x8048444: main (main.cpp:19)
==3498== Address 0x40c0500 is in the Text segment of /lib/i386-linux-gnu/libc-2.15.so
コードエラーはmalloc()をmalloc[]と書き、malloc関数ポインタの後ろのアドレスを取得したことに相当し、出力レポートはこのアドレスが位置していることを示す.textセグメント.
レポートの基本的なフォーマットは次のとおりです.
{ }
at { 、 、 }
by { 、 、 }
by ...{ }
Address 0x???????? { }
レポートの出力ドキュメント全体のフォーマットは、次のようにまとめられます.
1. copyright
2.
2.1
2.2 A
2.3 B
2...
3.
3.1 (HEAP SUMMARY)
3.2 (definitely lost)
3.3 (show-reachable=no )
3.4 (LEAK SUMMARY)
一般的な異常レポート
メモリリーク
int main(int argc, char *argv[])
{
char* bigBuff = (char*)malloc(1024);
}1,024 bytes in 1 blocks are definitely lost in loss record 1 of 1
at 0x402BE68: malloc (in /usr/lib/valgrind/vgpreload_memcheck-x86-linux.so)
by 0x8048414: main (main.cpp:17)
definitely lost:メモリは解放されず、ここにポインタはありません.漏れたに違いない.レポートに示されるスタックは、メモリが割り当てられたときの呼び出しスタックであり、メモリがどのビジネスロジックによって作成されたかを基本的に明確にすることができます.still reachable:メモリが解放されていないということですが、ポインタがあり、メモリが使用されているので、漏洩ではありません.(プログラムが終了しても動作する非同期システム呼び出し?)possibly lost:漏れがある可能性があり、一般的には2次ポインタ(ポインタのポインタ)など複雑な状況が追跡しにくい場合に発生します.suppressed:valgrindを使用するパラメータの一部が特定のライブラリをキャンセルしたエラーを統計し、ここにまとめられます.
いじょうほうしゅつ
int main(int argc, char *argv[])
{
char* bigBuff = (char*)malloc(1024);
char* offsetBuff = bigBuff + 888;
free(offsetBuff);
} Invalid free() / delete / delete[] / realloc()
at 0x402B06C: free (in /usr/lib/valgrind/vgpreload_memcheck-x86-linux.so)
by 0x8048461: main (main.cpp:24)
Address 0x41f23a0 is 888 bytes inside a block of size 1,024 alloc'd
at 0x402BE68: malloc (in /usr/lib/valgrind/vgpreload_memcheck-x86-linux.so)
by 0x8048444: main (main.cpp:17)
free()/delete/delete[]/realloc()の4つのいずれかで、freeの不正な解放です.アドレスの相対関係を記述する際に、Address 0 x???という文を使用します.is {x} bytes {inside/before/after} a block of size {y} {alloc’d/free’d}
これは、解放されたアドレスとy長ブロックとの相対的な位置関係を表す.アドレスがブロックの前にある場合はbefore,ブロック内にある場合はinside,ブロックの後にafterを用いる.最後のalloc’dは、このy長のブロックが有効な状態にあることを表し、その割り当て時のスタックは以下の通りである.free’dはy長ブロックが削除されたことを表し、その削除時のスタックは以下の通りである.
従って、上記の報告は、アドレス0 x 41 f 23 a 0が長さ1024の有効ブロック内+888に位置し、その割り当て時の呼び出しスタックは以下のように解釈される.
不正な読み書き
int main(int argc, char *argv[])
{
char* bigBuff = (char*)malloc(1024);
uint64_t* bigNum = (uint64_t*)(bigBuff+1020);
*bigNum = 0x12345678AABBCCDD;
printf("bigNum is %llu
",*bigNum);
free(bigBuff);
}Invalid write of size 4
at 0x8048490: main (main.cpp:19)
Address 0x41f2428 is 0 bytes after a block of size 1,024 alloc'd
at 0x402BE68: malloc (in /usr/lib/valgrind/vgpreload_memcheck-x86-linux.so)
by 0x8048474: main (main.cpp:17)
Invalid read of size 4
at 0x804849B: main (main.cpp:20)
Address 0x41f2428 is 0 bytes after a block of size 1,024 alloc'd
at 0x402BE68: malloc (in /usr/lib/valgrind/vgpreload_memcheck-x86-linux.so)
by 0x8048474: main (main.cpp:17)
1つのメモリ領域の使用が割り当てられた時間を超えると、Invalid write/readがトリガーされ、長さが通知されます.この例ではuint 64_tは8バイト長で,アクセスは4バイトを超えた.bigBuff+1020をbigBuff-20に変更すると、Address xxx is 20 bytes before a block of...
もう一つ興味深い現象はuint 64_tの不正アクセスは4バイト長の不正アクセスのレポートを2回生成しますが、これは何を説明していますか?
不一致の解放
int main(int argc, char *argv[])
{
int unused;
char* bigBuff = (char*)malloc(1024);
delete[] bigBuff;
printf("unused=%d",unused);
}Mismatched free() / delete / delete []
at 0x402A8DC: operator delete[](void*) (in /usr/lib/valgrind/vgpreload_memcheck-x86-linux.so)
by 0x80484FB: main (main.cpp:19)
Address 0x4323028 is 0 bytes inside a block of size 1,024 alloc'd
at 0x402BE68: malloc (in /usr/lib/valgrind/vgpreload_memcheck-x86-linux.so)
by 0x80484E4: main (main.cpp:18)
Use of uninitialised value of size 4
at 0x416E0DB: _itoa_word (_itoa.c:195)
by 0x417221A: vfprintf (vfprintf.c:1629)
by 0x4178B2E: printf (printf.c:35)
by 0x41454D2: (below main) (libc-start.c:226)
Mismatched free()/delete/delete[]レポートは、mallocの割り当て後にdeleteを使用してもdelete[]を使用しても、new[]を使用しても不注意にdeleteを使用しても取得され、レポート主体の内容はほぼ一致します.
初期値の使用
上記の例ではint unusedは値を付けずに使用され、このような問題は通常致命的ではないが、排除する必要があるというUse of uninitialised value of size 4の報告が得られた.
興味深いことに、スタックの最後のレイヤに初めて(below main)が現れ、main関数以外でコードが実行されていることを示しています.スレッドから来ているわけではありません.私はまだこの現象を明確に説明できませんが、次のテストをしました.
静的構造と解放
class GlobalClass
{
public:
GlobalClass()
{
char* buf = (char*)malloc(10);
*(int*)(buf+8) = 100;
free(buf);
}
~GlobalClass()
{
char* buf = (char*)malloc(10);
*(int*)(buf+8) = 100;
free(buf);
}
void fake(){}
} g_globalClass;
int main(int argc, char *argv[])
{
g_globalClass.fake();
}Invalid write of size 4
at 0x804857B: GlobalClass::GlobalClass() (main.cpp:21)
by 0x804850F: __static_initialization_and_destruction_0(int, int) (main.cpp:31)
by 0x8048551: _GLOBAL__sub_I_g_globalClass (main.cpp:55)
by 0x8048631: __libc_csu_init (in /home/jinzeyu/codelocal/build-mcsample-Desktop_Qt_5_3_GCC_32bit-Debug/mcsample)
by 0x4060469: (below main) (libc-start.c:185)
Address 0x41f2030 is 8 bytes inside a block of size 10 alloc'd
at 0x402BE68: malloc (in /usr/lib/valgrind/vgpreload_memcheck-x86-linux.so)
by 0x8048571: GlobalClass::GlobalClass() (main.cpp:20)
by 0x804850F: __static_initialization_and_destruction_0(int, int) (main.cpp:31)
by 0x8048551: _GLOBAL__sub_I_g_globalClass (main.cpp:55)
by 0x8048631: __libc_csu_init (in /home/jinzeyu/codelocal/build-mcsample-Desktop_Qt_5_3_GCC_32bit-Debug/mcsample)
by 0x4060469: (below main) (libc-start.c:185)
Invalid write of size 4
at 0x80485B9: GlobalClass::~GlobalClass() (main.cpp:27)
by 0x4079B80: __run_exit_handlers (exit.c:78)
by 0x4079C0C: exit (exit.c:100)
by 0x40604DA: (below main) (libc-start.c:258)
Address 0x41f2070 is 8 bytes inside a block of size 10 alloc'd
at 0x402BE68: malloc (in /usr/lib/valgrind/vgpreload_memcheck-x86-linux.so)
by 0x80485AF: GlobalClass::~GlobalClass() (main.cpp:26)
by 0x4079B80: __run_exit_handlers (exit.c:78)
by 0x4079C0C: exit (exit.c:100)
by 0x40604DA: (below main) (libc-start.c:258)
静的クラスの構造と解放はmainの外にあるので,(below main)の文字が現れ,スタックの関数名もこの2つのプロセスをよく確認した.ここでもう一つの問題を連想したのは,静的構造の順序が必ずしも予想通りではなく,静的オブジェクト間に依存関係がないことを強く提案することである.
クラッシュ
memcheckがあなたのプログラムを実行している間にクラッシュに遭遇した場合、それは依然としていくつかの役に立つ情報を提供することができます.
--16198-- VALGRIND INTERNAL ERROR: Valgrind received a signal 11 (SIGSEGV) - exiting
--16198-- si_code=1; Faulting address: 0x74207972; sp: 0x6564ca5c
valgrind: the 'impossible' happened:
Killed by fatal signal
==16198== at 0x380C0AD4: ??? (in /usr/lib/valgrind/memcheck-x86-linux)
==16198== by 0x380C12C5: ??? (in /usr/lib/valgrind/memcheck-x86-linux)
==16198== by 0x38040A63: ??? (in /usr/lib/valgrind/memcheck-x86-linux)
==16198== by 0x38040B36: ??? (in /usr/lib/valgrind/memcheck-x86-linux)
==16198== by 0x3803EA4B: ??? (in /usr/lib/valgrind/memcheck-x86-linux)
==16198== by 0x20202E78: ???
sched status:
running_tid=3
次に、クラッシュ時に各スレッドが置かれているスタックとスレッドの実行状態を順にレポートします.
Thread 1: status = VgTs_WaitSys
...
Thread 2: status = VgTs_WaitSys
...
Thread 3: status = VgTs_Runnable
==16198== at 0x402C9B4: operator new(unsigned int) (in /usr/lib/valgrind/vgpreload_memcheck-x86-linux.so)
==16198== by 0x437D7D3: std::string::_Rep::_S_create(unsigned int, unsigned int, std::allocator const&) (in /usr/lib/i386-linux-gnu/libstdc++.so.6.0.16)
==16198== by 0x437FBB5: std::basic_string, std::allocator >::basic_string(char const*, std::allocator const&) (in /usr/lib/i386-linux-gnu/libstdc++.so.6.0.16)
==16198== by 0x82A76A3: DataChecker::handle_data_check_resp_msg(void*) (data_checker.c:55)
==16198== by 0x8144411: main_thread(void*) (main_thread.c:198)
==16198== by 0x82839CF: thread_manager_start_routine(void*) (thread_manager.c:72)
==16198== by 0x42D3D4B: start_thread (pthread_create.c:308)
==16198== by 0x450BFDD: clone (clone.S:130)
Thread 4: status = VgTs_WaitSys
...
では,実行中のスレッドは疑いが最も大きく,スタック情報を抽出してさらに解析することができる.