2017-12-20 44 views
-3

私は長い時間をかけて実行しているバイナリプログラムのヒープ増加問題をデバッグするためにmassifを使用しています。だから私はvalgrindの--tool = memcheck -vをしようと試み、それが報告valgrind memcheckは "rw-匿名セグメントで"メッセージを返します

valgrind: m_mallocfree.c:280 (mk_plain_bszB): Assertion 'bszB != 0' failed. 
valgrind: This is probably caused by your program erroneously writing past the 
end of a heap block and corrupting heap metadata. If you fix any 
invalid writes reported by Memcheck, this assertion failure will 
probably go away. Please try that before reporting this as a bug. 
host stacktrace: 
==21766== at 0x58007769: show_sched_status_wrk (in /usr/lib64/valgrind/massif-amd64-linux) 
==21766== by 0x58007A44: report_and_quit (in /usr/lib64/valgrind/massif-amd64-linux) 
==21766== by 0x58007C77: vgPlain_assert_fail (in /usr/lib64/valgrind/massif-amd64-linux) 
==21766== by 0x58013D01: vgPlain_arena_free (in /usr/lib64/valgrind/massif-amd64-linux) 
==21766== by 0x5805CAE2: do_client_request (in /usr/lib64/valgrind/massif-amd64-linux) 
==21766== by 0x5805DCFE: vgPlain_scheduler (in /usr/lib64/valgrind/massif-amd64-linux) 
==21766== by 0x58011560: final_tidyup (in /usr/lib64/valgrind/massif-amd64-linux) 
==21766== by 0x5801191B: shutdown_actions_NORETURN (in /usr/lib64/valgrind/massif-amd64-linux) 
==21766== by 0x5808F42C: run_a_thread_NORETURN (in /usr/lib64/valgrind/massif-amd64-linux) 

sched status: 
    running_tid=1 

Thread 1: status = VgTs_Runnable (lwpid 21766) 
==21766== at 0x4A06F16: free (vg_replace_malloc.c:529) 
==21766== by 0x3CD630C24A: free_mem (in /lib64/libc-2.5.so) 
==21766== by 0x3CD630BE41: __libc_freeres (in /lib64/libc-2.5.so) 
==21766== by 0x480368A: _vgnU_freeres (vg_preloaded.c:77) 
==21766== by 0x3CD6233224: exit (exit.c:90) 
==21766== by 0x3CD621D9FA: (below main) (libc-start.c:262) 

を:しかし、それは報告

==21789== HEAP SUMMARY: 
==21789==  in use at exit: 0 bytes in 0 blocks 
==21789== total heap usage: 7,015 allocs, 7,016 frees, 805,222 bytes allocated 
==21789== 
==21789== All heap blocks were freed -- no leaks are possible 
==21789== 
==21789== ERROR SUMMARY: 1 errors from 1 contexts (suppressed: 6 from 4) 
==21789== 
==21789== 1 errors in context 1 of 1: 
==21789== Invalid free()/delete/delete[]/realloc() 
==21789== at 0x4A08B56: free (vg_replace_malloc.c:529) 
==21789== by 0x3CD630C24A: free_mem (in /lib64/libc-2.5.so) 
==21789== by 0x3CD630BE41: __libc_freeres (in /lib64/libc-2.5.so) 
==21789== by 0x480368A: _vgnU_freeres (vg_preloaded.c:77) 
==21789== by 0x3CD6233224: exit (exit.c:90) 
==21789== by 0x3CD621D9FA: (below main) (libc-start.c:262) 
==21789== Address 0x6374c98 is in a rw- anonymous segment 
==21789== 
--21789-- 
--21789-- used_suppression:  6 dl-hack3 /usr/lib64/valgrind/default.supp:1239 
==21789== 
==21789== ERROR SUMMARY: 1 errors from 1 contexts (suppressed: 6 from 4) 

私はメインの下に何かエラーのためのアイデアを得ませんでした。

+0

あまりにも悪いValgrind Memcheckは面白いことを指摘していません。上記のMemcheckはあなたが書いたコードを呼び出しますか?それとも定型文のライブラリコードですか?おそらく '/ usr/lib64/valgrind/default.supp'を避けると、より有用な情報が表示されます。 dtorとfini関数では奇妙なことが起こります。プログラマーの中には、プログラムの終了時に非常に混乱する可能性があると感じるプログラマーもいます。クリーンアップルーチンのいずれかがあなたの機能のように見えますか? – jww

答えて

0

malloc/free/..(例:memcheckとmassif)に置き換わるツールでは、valgrindはデフォルトで実行されます。glibcは、例えばglibcに割り当てられたメモリを解放する関数を提供します。 C++ランタイムまたはいくつかのglibc /動的ローダーデータ構造体 。 これにより、「メモリリークフリー」レポートが可能になります。しかし、glibcクリーナーが、valgrindが傍受していないもの(おそらく「早すぎる」割り振り?これは不明です)によって割り当てられたメモリを解放しようとしているようです。

行うには2つのこと:

  • 実行--run-libcの-freeres =無--run-CXX-freeresで=問題を回避するには、no。 ...
  • 、 は、gccのバージョン、glibcのバージョン、配布、valgrindのバージョンなどの詳細情報を必要なすべてのTNEを与え、
  • ファイルvalgrindののはbugzillaに上記のバグ(あなたは、まだ割り当てられたメモリの一部に文句memcheck表示される場合があります)
関連する問題