c - Valgrind - 抑制ファイルが一般的すぎる?

Question

私はvalgrindを初めて使用し、最初に気付いたのは、OS X El Capitanの標準C-Libraryがメモリをリークしているように見えることです(おそらく失われました)。もう少し読んだ後、これは事実ではなく、抑制ファイルを使用してvalgrind リークの概要から system-lib を除外することができます。

そのような抑制ファイルを 1 つ生成し (単純なプログラムを実行して)、抑制ファイルにエラーを追加しました。次のようになります。

osx_el_capitan_c_lib.supp

{
  <osx_el_capitan_c_lib>
   Memcheck:Leak
   match-leak-kinds: possible
   fun:malloc_zone_malloc
   fun:_objc_copyClassNamesForImage
   fun:_ZL9protocolsv
   fun:_Z9readClassP10objc_classbb
   fun:gc_init
   fun:_ZL33objc_initializeClassPair_internalP10objc_classPKcS0_S0_
   fun:layout_string_create
   fun:_ZL12realizeClassP10objc_class
   fun:_ZL22copySwiftV1MangledNamePKcb
   fun:_ZL22copySwiftV1MangledNamePKcb
   fun:_ZL22copySwiftV1MangledNamePKcb
   fun:_ZL22copySwiftV1MangledNamePKcb
}

今、私はいくつかの質問があります:

このファイルが私の実際のコード (system-libs ではない) のリークを抑制する可能性はありますか? 確実にリークしている/リークしていないコードで少しテストしましたが、正常に動作しているようです。しかし、どうすれば確信できますか？

デフォルトの出力電流は次のようになります (漏れていないことは間違いありません)。

    ==37004== Memcheck、メモリエラー検出器
    ==37004== Copyright (C) 2002-2015、GNU GPL'd、Julian Seward et al.
    ==37004== Valgrind-3.11.0 と LibVEX を使用。著作権情報については -h で再実行してください
    ==37004== コマンド: ./val.o
    ==37004==
    ==37004==
    ==37004== ヒープの概要:
    ==37004== 出口で使用中: 187 ブロックで 22,100 バイト
    ==37004== 合計ヒープ使用量: 271 個の割り当て、84 個の解放、28,340 バイトの割り当て
    ==37004==
    ==37004== リークの概要:
    ==37004== 確実に失われました: 0 ブロックに 0 バイト
    ==37004== 間接的に失われました: 0 ブロックで 0 バイト
    ==37004== 失われた可能性: 0 ブロックに 0 バイト
    ==37004== まだ到達可能: 0 ブロックに 0 バイト
    ==37004== 抑制: 187 ブロックで 22,100 バイト
    ==37004==
    ==37004== 検出され抑制されたエラーの数については、-v で再実行してください。
    ==37004== エラー概要: 0 コンテキストから 0 エラー (抑制: 18 から 18)

ご覧のとおり、抑制ファイルは今のところ問題なく機能しています (失われたバイトなどは表示されません)。しかし、ヒープの要約は抑制ファイルの影響を受けないようです ( allocs/mallocsが表示されます - それらは私のコードの外で発生します) 。このフィールド (フラグなど) を無効にして、ヒープサマリーでも (コード外の / ) を抑制する方法はありますか?allocsmallocs

c - Valgrind - 抑制ファイルが一般的すぎる?

0 に答える 0

Related

Reference