問題タブ [callgrind]

Callgrind は malloc でアサーション違反を報告しましたが、memcheck と通常の実行ではエラーは明らかになりません。

stp: malloc.c:3096: sYSMALLOc: アサーション `(old_top == (((mbinptr) (((char *) &((av)->bins[((1) - 1) * 2])) - __builtin_offsetof (struct malloc_chunk, fd)))) && old_size == 0) || ((unsigned long) (old_size) >= (unsigned long)((((__builtin_offsetof (struct malloc_chunk, fd_nextsize))+((2 * (sizeof(size_t))) - 1)) & ~(((2 * (sizeof) (size_t))) - 1))) && ((old_top)->size & 0x1) && ((unsigned long)old_end & pagemask) == 0)' が失敗しました。

実行コマンドは次のとおりです。

taskset -c 7 valgrind --main-stacksize=256768768 --tool=callgrind no-asserts-no-cbitp/stp ~/profiling-stp/python-samples-without-const-arr/*.smt

プログラムは -O2 -g オプションでビルドされます。valgrind を実行する前に、「ulimit -s unlimited」が呼び出されます。

Callgrind によって報告されたエラーのスタック トレースを取得することは可能ですか? そうでない場合 - デバッグ方法のアイデアはありますか?

ありがとう！

kcachegrind で gprof の出力を表示するには? gcc の gmon.out から callgrind.out へのコンバーターはありますか?

kcachegrind/callgrind が奇妙な結果を報告するモデル コードがあります。一種のディスパッチャー機能です。ディスパッチャーは 4 つの場所から呼び出されます。各呼び出しは、実行する実際のdo_J関数を示します（したがって、first2呼び出しのみdo_1などdo_2）

ソース (これは実際のコードのモデルです)

でコンパイルgcc -O0; コールグラインドvalgrind --tool=callgrind; kcachegrindedkcachegrindとqcachegrind-0.7.

以下は、アプリケーションの完全なコールグラフです。do_J へのすべてのパスはディスパッチャーを通過します。これは適切です (do_1 は速すぎるとして隠されていますが、実際にはここにあり、do_2 に残されています)。

誰がそれを呼び出したかに注目しdo_1て確認しましょう (この図は正しくありません)。

そして、これは非常に奇妙だと思いますが、すべてではfirst2ありません。outer2do_1

callgrind/kcachegrind の制限ですか? 重み付きで正確なコールグラフを取得するにはどうすればよいですか (すべての関数の実行時間に比例し、その子の有無にかかわらず)。

http://valgrind.org/docs/manual/cl-manual.htmlを使用 してアプリケーションのプロファイルを作成しています。しかし、私はそれがo/pであるかについて質問があります

1. その関数内で消費された時間

また

1. その関数呼び出し内で消費されたcpU

私が推測するのは、現在、curl connectで90％の使用率を示しているということです。どちらがI/Oバウンドプロセスだと思います。

したがって、その関数呼び出し内で消費された時間を示していると思います。

ログをプロファイリングすると、Kcachegrind は %of inclusive を 13.92% と表示します。FAQ Q:1に記載されているように、100% に近いはずではありませんか??

これはプロファイルログのスクリーンショットです

アプリケーションがスレッド数に比例してスケーリングするという問題があります (デュアル コア CPU では、800 スレッドで 400 スレッドのパフォーマンスが 2 倍になると考えてください)。そして、私の直感は、スレッドがスリープしているかブロックされていることを教えてくれます...しかし、callgrindでそれを見ることはできません。

同様に、callgrind は関数の時間、またはデータを作成するためにスレッドがアクティブだった時間を測定します。私が何を尋ねるかが明確でない場合...スレッドは

2秒間、その後

...i++コール グラフの約 100% または約 66% になります。

私は callgrind を使用して Linux マルチスレッド アプリのプロファイリングを行っていますが、ほとんどの場合うまく機能しています。インストルメンテーションをオフ ( --instr-atstart=no ) で開始し、セットアップが完了したら、 callgrind_control -i on でオンにします。ただし、特定の構成を変更してアプリの別の部分をプロファイリングしようとすると、インストルメンテーションをオンにする前でも実行が非常に遅くなります。基本的に、通常の操作では数秒かかるコードの一部が、callgrind (インスツルメンテーションがオフ) では 1 時間以上かかります。その理由と、遅さのデバッグ/解決方法についてのアイデアはありますか?

私はkCacheGrind（実際にはWinCacheGrind）を分析してcachegrindファイルを分析していますが、各プロセスの「自己」時間を合計すると、合計はページ全体の累積時間に近くなりません。具体的には、ページ全体のセルフタイムは6,561ミリ秒ですが、{main}内の子の累積時間は合計で96ミリ秒にすぎません。

「行方不明」の時間を特定するための最善の方法はありますか？

残念ながら、私は新しいので画像を含めることはできませんが、うまくいけば、始めるのに十分な量を与えました。そうでない場合は、私が提供できるものを教えてください。

ありがとう。

編集：これが私が見ているものですhttp://www.flickr.com/photos/76072991@N02/6832545235/

アプリの動的コール グラフが必要です。callgrindツール（valgrindスイート）で実行し、callgrind.out.xxxxxファイルを取得しました。ここで、このデータをグラフィカルに表現したいと思います。KCacheGrindグラフの限られた部分を描画するため、あまり役に立ちません（プロファイルされた〜1500の代わりに〜50の関数を描画し、それを修正する方法がわかりません）。すべての関数が描画されるグラフ イメージを取得するにはどうすればよいですか?

時間が費やされている場所をプロファイリングするためのツールを探しています。oprofile を見てきましたが、本当に必要なものが得られません。

私は、特に CALLGRIND_START_INSTRUMENTATION および CALLGRIND_STOP_INSTRUMENTATION マクロを使用して、callgrind を見ていました。valgrind が一般的に行うように、ツールによってアプリの速度が低下することは望ましくありません。しかし、Valgrind はすべてを 1 つのスレッドにシリアライズしているように見えるため、実際には機能しません。

たとえば、fn A が fn C を呼び出す fb B を呼び出し、B と A に戻る場合、どこでどのくらいの時間が費やされたかを知りたいと考えています。私は使用しているいくつかのミューテックス ツールを持っていますが、適切な時間ツールは、正確にどこに時間が費やされているかを確認するのに非常に役立ち、それらのパスに集中することができます。自分で何かを追加する以外に、このタスクに使用できるツールはありますか? そのC ++アプリところで。valgrind は、カーネルがシングル スレッドであるため使用できません。また、私のアプリは待機に多くの時間を費やしているため、単純な CPU プロファイラーは実際にはあまり役に立ちません..