ご存知の方もいらっしゃるかもしれませんが、Googleがc ++コードを分析するためのツールの無料のすばらしいコレクションを提供しています： http ：//code.google.com/p/google-perftools/
問題は、64ビットで明らかにlibunwindの問題があり、作成者がそれを修正するために自分の側で何もできないことです（
しかし、私はすぐに修正されるとは思っていません。それは、libcの人々とlibunwindの人々がいくつかのロックの問題を解決することに依存しています。残念ながら、私たち自身ができることはあまりありません。
）、だから私は代替品を探しています。プロファイリングデータのクールなグラフィック表現を提供する同様のツールはありますか（例
:)
）。
編集：問題を説明するREADMEから貼り付けます：
2）x86-64 64ビットシステムでは、tcmalloc自体は正常に機能しますが、cpu-profilerツールは信頼性がありません。機能する場合もありますが、セグメンテーション違反が発生する場合もあります。最初に問題を説明し、次にいくつかの回避策を説明します。
これは、CPUPROFILE環境変数を設定して手動でオンにする必要があるgoogle-perftools機能であるcpu-profilerにのみ影響することに注意してください。CPUプロファイリングをオンにしない場合、perftoolsが原因でクラッシュが発生することはありません。
厄介な詳細：根本的な問題は、libcの組み込み関数であるbacktrace（）関数にあります。通常の場合、バックトレースはかなり簡単ですが、信号フレーム全体をバックトレースする必要がある場合に問題が発生する可能性があります。残念ながら、cpu-profilerはプロファイリングイベントを登録するために信号を使用するため、プロファイラーが実行するすべてのバックトレースは信号フレームを通過します。
私たちの経験では、問題が発生するのは、pthread_mutex_lockの途中で信号が発生したときだけです。pthread_mutex_lockは、特にプログラムの起動時や新しいスレッドの作成時に、システムライブラリからかなり呼び出されます。
解決策：dwarfデバッグ形式では、「cfiアノテーション」がサポートされているため、信号フレームを簡単に認識できます。Fedoraやgentoo2007.0などの一部のOSディストリビューションでは、すでにcfiアノテーションがlibcに追加されています。libunwindの将来のバージョンでは、これらのアノテーションを認識する必要があります。これらのシステムはクラッシュを認識しないはずです。
回避策：cpu-profilerの実行中にクラッシュの問題が発生した場合は、CPUPROFILEを設定するのではなく、コードにProfilerStart（）/ ProfilerStop（）を挿入することを検討してください。これにより、コードベースのそれらのセクションのみがプロファイルされます。多くのテストは行っていませんが、理論的には、信号の生成をコードベースのごく一部に制限することで、クラッシュの可能性を減らすことができます。理想的には、新しいスレッドを生成するコードの周りでProfilerStart（）/ ProfilerStop（）を使用しないか、そうでなければpthread_mutex_lockの呼び出しを引き起こす可能性があります。
---2011年5月17日