問題タブ [callstack]

プログラム (VS2008) をデバッグしていて、コード行をステップ実行していました。デリゲート関数が呼び出されている行に出くわし、その行にステップ インしようとしました。ただし、期待どおりにメソッドにステップインするのではなく、メソッドはバイパスされ、代わりに、デリゲートによって呼び出される関数であると想定されるものにデバッガーがステップインしました。コール スタックで、デリゲート メソッドがあると予想していた行は、テキストでグレー表示されています[Lightweight Function]。

「軽量機能」の部分とは？この関数にステップインする方法はありますか?

デバッグの場合、特定の関数がコール スタックの上位にあるかどうかを確認できると便利なことがよくあります。たとえば、特定の関数から呼び出されたときにだけデバッグ コードを実行したいことがよくあります。

1 つの解決策は、上位のすべてのスタック エントリを調べることですが、これがスタックの奥深くにあり、繰り返し呼び出される関数内にある場合、過剰なオーバーヘッドにつながります。問題は、特定の関数がコール スタックの上位にあるかどうかを合理的に効率的に判断できる方法を見つけることです。

似ている

• フレームオブジェクトから実行スタック上の関数オブジェクトへの参照を取得していますか? - この質問は、特定の関数にいるかどうかを判断するのではなく、関数オブジェクトを取得することに焦点を当てています。同じ手法を適用できますが、非常に非効率になる可能性があります。

たとえば、C# で例外処理スタック フレームがコール スタックにプッシュされる順序は何ですか。メソッドがある場合：

次のように、例外ハンドラごとに個別のスタック フレームが作成されますか?

また

また

他の何か？

プログラムには 2 つのスタックがあります。1 つは OS によって作成され、2 つ目はコードを実行するためにプログラム自体によって作成されます。

2 番目のスタックでプログラムがクラッシュした場合、gdb のメイン スタックに切り替えて、バックトレースを確認したいと考えています。出来ますか？

rsp を変数に保存し、クラッシュ後に変更しようとしましたが、結果のバックトレースは正しくありませんでした。gdb はスタック内のフレームを区別できないと思います。

スタックのクリーンアップの責任者を知りたい

次のように言うことができる関数 fun があるとします。

fun呼び出されると、パラメータとともにスタックに入り、関数が返されたときにスタックのクリーンアップを担当するのは、関数自体または戻り値を保持する「var」です。

もう1つ、呼び出し規約の概念を説明できる人はいますか?

My answer for a recent question about GOTOs and tail recursion was phrased in terms of a call stack. I'm worried that it wasn't sufficiently general, so I ask you: how is the notion of a tail call (or equivalent) useful in architectures without a call stack?

In continuation passing, all called functions replace the calling function, and are thus tail calls, so "tail call" doesn't seem to be a useful distinction. In messaging and event based architectures, there doesn't seem to be an equivalent, though please correct me if I'm wrong. The latter two architectures are interesting cases as they are associated with OOP, rather than FP. What about other architectures? Were the old Lisp machines based on call-stacks?

Edit: According to "What the heck is: Continuation Passing Style (CPS)" (and Alex below), the equivalent of a tail call under continuation passing is not "called function replaces calling function" but "calling function passes the continuation it was given, rather than creating a new continuation". This type of tail call is useful, unlike what I asserted.

Also, I'm not interested in systems that use call stacks at a lower level, for the higher level doesn't require a call stack. This restriction doesn't apply to Alex's answer because he's writing about the fact that other invocation architectures (is this the right term?) often have a call stack equivalent, not that they have a call stack somewhere under the hood. In the case of continuation passing, the structure is like an arborescence, but with edges in the opposite direction. Call stack equivalents are highly relevant to my interests.

理論的な質問。以下の静的メソッドを呼び出すaspxWebページに100個の個別のリクエストが届く場合。

すべてのリクエストに個別のコールスタックがありますか？

もしそうなら-この静的メソッド呼び出しはこれらの別々の呼び出しスタックにプッシュされますか？

もしそうなら-したがって、これらのintはスレッドセーフですか？すなわち。100リクエスト、100コールフレーム、300int。

乾杯

私は何年にもわたって多くのゲーム プロジェクトでミニダンプを使用してきましたが、有効なコール スタックを持つ可能性は約 50% のようです。コールスタックを改善するにはどうすればよいですか?

最新の dbghelp.dll を exe ディレクトリに入れてみました。それはいくつかを助けるようです。

Visual Studio 2008 または 2010 はどちらが優れていますか? (私はまだ VS 2005 を使用しています)。

私が使用するコードは、このサンプルのようになります。

Specman でスタック トレースを取得する方法はありますか? シグナルが強制されたときにシグナルを強制的に通知する関数にパッチを適用しました。強制がどこで発生したかを知りたいです。

MySpace.comのチーフ システム アーキテクトである Dan Farino による素晴らしいプレゼンテーションがあり、特定のプロセスで実行されているすべてのスレッド (スレッドの実行内容、実行時間など) をカタログ化する Web ベースのスタック ダンプ ツールを紹介しています。 .)

彼らのテクニックは、 highscalability.comにもまとめられています。

• パフォーマンスコレクター。
  UDP によるパフォーマンス データの集中収集。Windows よりも信頼性が高く、あらゆるクライアントが接続して統計情報を表示できます。
• Web ベースのスタック ダンプ ツール。
  問題のあるサーバーを右クリックして、.Net 管理スレッドのスタック ダンプを取得できます。以前は、システムに RDC を接続してデバッガーを接続し、1/2 後に回答を得なければなりませんでした。遅く、拡張性がなく、退屈です。単なるスタック ダンプではなく、スレッドが何をしているかについて多くのコンテキストを提供します。データベースで 90 個のスレッドがブロックされていることがわかり、データベースがダウンしている可能性があるため、トラブルシューティングが容易になります。
• Web Base ヒープ ダンプ ツール。
  すべてのメモリ割り当てをダンプします。開発者にとって非常に便利です。手作業で何時間も節約できます。• プロファイラー。要求を最初から最後まで追跡し、レポートを生成します。URL、メソッド、ステータスなど、遅いリクエストを特定するのに役立つすべてを確認します。ロックの競合を調べたり、多くの例外がスローされたり、興味深いことは何でも調べます。非常に軽量。本番環境では、VIP (100 サーバーのグループ) ごとに 1 つのボックスで実行されています。10 秒ごとに 1 つのスレッドをサンプリングします。常にバックグラウンドでトレースします。

問題は、ASP.NET 用の Web ベースのスタック ダンプ ツールを構築するには、どのツールが必要かということです。便宜上、ターゲット AppDomain でホストされている *.aspx で、そのプロセスのすべてのマネージ コール スタックを出力できると仮定しましょう。

Mdbg (C#/IL で完全に記述され、CLR 2 SDK で出荷が開始されたマネージ コード用のデバッガー) と、通常は C:\Program Files\Microsoft Visual Studio 8\SDK\ にあるmdbgcoreアセンブリの使用をカバーする投稿がいくつかあります。 v2.0\ビン:

• http://dotnetdebug.ne​​t/2005/11/09/exceptiondbg-v01-debug-your-exceptions/
• http://blogs.msdn.com/jmstall/archive/tags/MDbg/default.aspx
• http://blogs.msdn.com/vijaysk/archive/2009/11/04/asp-net-debugger-extension-for-iis-7.aspx

ソリューションは、単にこのアセンブリを参照して、目的の出力を生成しますか? 「管理されているすべての呼び出しスタックを一覧表示する」操作は、運用トラフィックを処理している実行中のプロセスにどのような影響を与えますか?