5

OS X 10.8.1、Mountain Lion で Valgrind バージョン 3.8.0 を使用しています。10.8.1 との互換性について、Valgrind のサイトには次のように書かれています (イタリック体の鉱山):

Valgrind 3.8.0 は{x86,amd64}-darwin (Mac OS X 10.6 および 10.7、10.8 のサポートは限定的) で動作します。

したがって、10.8.1 の「限定的なサポート」しかないことはわかっています。それにもかかわらず、このバグレポートには次のように書かれています（イタリック体の鉱山）：

これ(最新の 3.8.0 リリース)により、Valgrindが コンパイルされ、OSX 10.8 で小さなプログラムを実行できるようになります。ただし、より大きなアプリではまだアサートされ、32 ビット プログラムはまったく適切にチェックされないことに注意してください (ほとんどのエラーは Memcheck によって見落とされます)。

OK、それは大丈夫です。そのため、Valgrind は 10.8.1 で動作するはずです。だから今私の質問：

ほとんど問題なく Valgrind を 10.8.1 でコンパイルすることができましたが、いくつかの小さな C プログラムで実行すると、奇妙な結果がいくつか見られました。問題の考えられる原因を減らすために、最終的に次の「プログラム」を作成しました。

int main () {                                                               
    return 0;
}

あまりエキサイティングではなく、バグの余地はほとんどないと思います。次に、コンパイルして Valgrind で実行しました。

gcc testC.c
valgrind ./a.out

ここに私の出力があります：

==45417== Command: ./a.out
==45417== 
==45417== WARNING: Support on MacOS 10.8 is experimental and mostly broken.
==45417== WARNING: Expect incorrect results, assertions and crashes.
==45417== WARNING: In particular, Memcheck on 32-bit programs will fail to
==45417== WARNING: detect any errors associated with heap-allocated data.
==45417== 
--45417-- ./a.out:
--45417-- dSYM directory is missing; consider using --dsymutil=yes
==45417== 
==45417== HEAP SUMMARY:
==45417==     in use at exit: 58,576 bytes in 363 blocks
==45417==   total heap usage: 514 allocs, 151 frees, 62,442 bytes allocated
==45417== 
==45417== LEAK SUMMARY:
==45417==    definitely lost: 8,624 bytes in 14 blocks
==45417==    indirectly lost: 1,168 bytes in 5 blocks
==45417==      possibly lost: 4,925 bytes in 68 blocks
==45417==    still reachable: 43,859 bytes in 276 blocks
==45417==         suppressed: 0 bytes in 0 blocks
==45417== Rerun with --leak-check=full to see details of leaked memory
==45417== 
==45417== For counts of detected and suppressed errors, rerun with: -v
==45417== ERROR SUMMARY: 0 errors from 0 contexts (suppressed: 0 from 0)

Valgrind が 10.8.1 のプライムタイムに対応する準備ができていないことはわかっています。それにもかかわらず、私はここでそれを使用できることを望んでいます.小さなプログラムでのみ使用する必要があり、結果がスポットオンであることについてミッションクリティカルなものは何もありません. しかし明らかに、リークの可能性が非常に低いと思われるプログラムで大量のリークが報告されています。したがって：

これを修正するにはどうすればよいですか?

他の情報：

  • 意図的にリークされた整数を追加すると、「確実に失われた」カウントが適切な 4 バイトだけ増加します。
  • 同様に、意図的にメモリを解放せずに malloc の呼び出しをリークすると、ヒープ割り当てカウントが適切に増加します。
  • フラグを指定してコンパイルし、-g(エラーに対処するために) Valgrind を実行すると、dSYM directory is missingそのエラーは消えますが、大量のメモリ リークが報告される問題は変わりません。
4

3 に答える 3

6

Valgrindトランクは、現在使用できるように改善されたようです。まだクラッシュしていませんが、多くの誤検知があり、抑制ファイルを使用して処理できます。

現在、私の抑制ファイルは次のようになっています。

# OS X 10.8 isn't supported, has a bunch of 'leaks' in the loader
{
   osx_1080_loader_false_positive_1
   Memcheck:Leak
   ...
   fun:_ZN11ImageLoader23recursiveInitializationERKNS_11LinkContextEjRNS_21InitializerTimingListE
   ...
}
{
   osx_1080_loader_false_positive_2
   Memcheck:Leak
   ...
   fun:_ZN16ImageLoaderMachO16doInitializationERKN11ImageLoader11LinkContextE
   ...
}
{
   osx_1080_loader_false_positive_3
   Memcheck:Leak
   ...
   fun:map_images_nolock
   ...
}
{
   osx_1080_loader_false_positive_4
   Memcheck:Leak
   ...
   fun:_objc_fetch_pthread_data
   fun:_ZL27_fetchInitializingClassLista
   fun:_class_initialize
   fun:_class_initialize
   fun:_class_initialize
   fun:_class_initialize
   fun:prepareForMethodLookup
   fun:lookUpMethod
   fun:objc_msgSend
   fun:_libxpc_initializer
   fun:libSystem_initializer
}
于 2013-01-22T18:07:13.057 に答える
6

それはすぐそこにあなたを教えてくれます：

不正確な結果、アサーション、およびクラッシュが予想されます。

それでも実行したい場合は、スプリアス リークに関する詳細情報を出力し ( --leak-check=full)、それを使用してそれらに関するメッセージを抑制します。

于 2012-09-17T05:09:26.290 に答える