問題タブ [backtrace]

Visual C# を使用して、大規模な C# プロジェクトをデバッグしています。プロジェクトは非常に大規模で、一部の pdb のみが自分で構築されています。すべての pdb をビルドできますが、非常に時間がかかります。バックトレースをデバッグしていますが、トレースの一部に [External Code] が付いています。一部の pdb が欠落していることはわかっていますが、外部コードが存在する DLL をどのように知ることができますか? CI では EIP を取得し、プロセス マッピングを参照して EIP が存在する場所を特定できますが、これを .Net 環境でどのように行うことができますか?

私はサーバープログラムを持っていますが、これは非常にクリーン/グレースフルなシャットダウンをしていません (一般的に終了することは想定されていません)。メモリ リークをトレースするときは valgrind で実行しますが、最終的にはプロセスをシグナル (^C) で強制終了する必要があります。通常、環境が静かなときにプロセスを終了しようとしますが、それでも一部のスレッドがジョブの処理でビジーであり、それらが保持するメモリが誤ったアラームを引き起こす可能性があります。このような分析を支援するために、valgrind に何らかの方法 (ツール) があり、プログラムが終了したときに (シグナルによって) スレッドのバックトレースを出力できますか?

私は function を認識していますdebug_backtraceが、次のような関数の実装をすぐに使用できるものを探していGetCallingMethodName()ますか? メソッドのクラスも指定すれば完璧です (それが実際にメソッドである場合)。

私が構築しているいくつかのインターフェースの多くの場所でカスタムエラーをスローしたいと考えています。関数内でエコーを使用するだけで、ページのタグの上にコードがエコーされます。そのため、エラーを処理してバックトレースを提供するカスタム関数を作成しましたが、これもページの上に出力されます。

これが私が使用している機能です：

ページのタグ内にエラーを出力するにはどうすればよいですか?

または、これを行うためのより良い方法はありますか?

SunOS 5.10 を使用してライブラリ (具体的にはprotbuf-2.3.0 ) をコンパイルしました。-g -O0

make ログのサンプル行は次のとおりです。

次に、次の手順を使用して gdb をアタッチしました。

1. アプリケーションを実行します (この場合、起動時に jni を介してライブラリを使用する Java Web アプリを起動する Web サーバー)。
2. gdb をそのプロセスに接続しましたgdb -p XXX(XXX は から取得した pid ですps)。
3. そしてfile libprotobuf.so、gdbプロンプトから使用して、gdbからライブラリをロードしました。

しかし、 から関数名が表示されませんbt。私の GDB バックトレース コマンドは次のように表示されます。

#1 & #2のみ、#1 & #3のみ、#1 & もやってみgdb libprotobuf.so -p XXXました。

それらとは別に、デバッグモードでjvmを実行して、System.loadLibrary(..)コマンドにブレークポイントを追加してみました。そのコマンドをステップオーバーした後、gdbアタッチプロセスを再度実行しました....しかし、まだ何もありません。

ただし、関数名を指定してブレークポイントを配置し、 を介して関数の内容を一覧表示することはできますlist。しかし、繰り返しになりますが、ブレークポイントを配置できますが、それらの関数名でも停止しません (jvm がクラッシュするたびに jvm hs_err_pid レポートにあるため、その関数に移動したことはわかっています)。

関数名が表示されないというアイデアはありますか？

backtrace10ミリ秒ごとにプロセスのスタック（スタック）を保存するgdbのスクリプトを作成したいと思います。これどうやってするの？

これは、「無一文」のコールグラフプロファイリングのようなものです（高度なプロファイラーを使用できない人向け）。

はい、多くの高度なプロファイラーがあります。一般的なCPUおよび一般的なOS用。Sharkは非常に印象的で使いやすいですが、gdbを使用して、このようなスクリプトで基本的な機能を取得したいと思います。

これはどういう意味ですか？デバッガーでブレークポイントをオンにして実行すると、コンソールにときどき表示されるようです。

ARM 9 で uclibc Linux を実行しています。問題は、uclibc がバックトレースをサポートしていないことです。コア ダンプが発生すると、コール スタックを取得できません。

誰かがそれに対する良い解決策を持っていますか?

たとえば、uclibc のバックトレースの既存の移植、またはコア ダンプが発生したときにコール スタックを取得するための適切な方法 (uclibc + ARM + Linux) はありますか?

起動時にフリーズする GCC でコンパイルされた C++ プログラムをデバッグしようとしています。GCC ミューテックスは関数の静的ローカル変数を保護しますが、そのようなロックを取得するのを待っていることが原因でフリーズしているようです。これがどのように起こるかはかなり混乱します。最初のモジュール A の静的初期化が発生し (GCC が呼び出す __static_init 関数がバックトレースに表示されます)、静的ローカル変数を持つ関数 Foo() が呼び出されます。静的ローカル変数は、コンストラクターが関数のいくつかのレイヤーを介して呼び出すオブジェクトであり、突然バックトレースにいくつかの ?? があり、2 番目のモジュール B の静的初期化にあります (__static 関数が何度も発生します)。 、その後 Foo() を呼び出しますが、Foo() が最初に返されなかったため、ローカル静的変数のミューテックスがまだ設定されており、ロックされています。

ある静的初期化が別の静的初期化をトリガーするにはどうすればよいですか? 私の最初の理論は共有ライブラリでした。モジュール A がモジュール B の関数を呼び出して、モジュール B をロードし、B の static init をトリガーするというものでしたが、そうではないようです。モジュール A はモジュール B をまったく使用しません。だから私は2番目の（そして恐ろしい）推測をしています。と言う：

1. モジュール A は、テンプレート化された関数またはテンプレート化されたクラスの関数を使用します。foo<int>::bar()

2. モジュール B も使用foo<int>::bar()

3. モジュール A はモジュール B にまったく依存していません

4. リンク時に、リンカーには の 2 つのインスタンスがありますがfoo<int>::bar()、テンプレート関数は弱いシンボルとしてマークされているため、これは問題ありません...

5. モジュール B はモジュール A に依存していませんが、実行時にモジュール A が を呼び出しfoo<int>::bar、モジュール B の static init がトリガーされます。なんで？リンカーは、リンク時にモジュール A のインスタンスではなく、モジュール B の foo::bar のインスタンスを使用することを決定したためです。

この特定のシナリオは有効ですか? それとも、あるモジュールの static init が別のモジュールで static init をトリガーすることはありませんか?

明確化: GCC はミューテックスを自動的に作成して、関数の静的変数を保護します。私はミューテックスで何もしていません。これは、関数の静的変数をスレッドセーフにする GCC の方法です。

更新:静的初期化は翻訳単位間で定義されておらず、順序に依存すべきではないことを知っています。しかし、問題をデバッグする手がかりとして、これが通常の動作であるかどうかに興味があります。コンパイラがこれを行うコードを生成するのは正常ですか、それとも GCC のバグを示している可能性がありますか?

完了キューの問題と思われるものをデバッグしようとしています。

それらの16進数を行番号に近いものに変えることは可能ですか？