問題タブ [stack-overflow]

自動生成されたアセンブリの1つがnew（）でStackOverflowExceptionをスローしていることを発見しました。このクラスには、コンストラクターで初期化される400以上の単純なプロパティがあります（ほとんどの場合、デフォルト（文字列）など）。

64ビットでは問題ありませんが、32ビットでは問題ありません。

コードジェネレーターを再設計する際に余裕を持たせるために、ユースケースでより大きなデフォルトスタックを作成することが合理的かどうかをテストする必要があります。

私たちは特にそうします。可能であればapp.configを含むソリューションに興味があります。しかし、私は現実主義者なので、何でもいいでしょう。

スタックオーバーフローの理由。問題のコンストラクターを絞り込みました。私の第一印象も無限再帰のタイプでした。ただし、次の3行のコンソールアプリを使用してエラーを再現しました。

• クラスの空のインスタンスを作成します。
• 最初の仕事はインスタンスを作成して空にすることであるクラスで非静的メソッド（Clone）を呼び出し、プロパティをに渡します。

2番目のコンストラクターにヒットすると、バタンと鳴ります。

.netソースコードを使用してデバッグしているところ、スタックオーバーフローがGuid.NewGuid（）にあり、これが2番目のパラメーターとしてコンストラクターに渡されていることがわかります。実際のコード行は、ネイティブCoCreateGuid（）呼び出しの呼び出しです。

したがって、CoCreateGuid（）のバグである可能性がありますが、コードを問題から排除したいと考えています。私の最初の考えは、スタックのサイズを大幅に増やして、このエラーが再発するかどうかを確認することです。次に、すべてのユースケースを制御できると思うので、コンストラクターをオブジェクトの初期化に置き換えます。これにより、スタックへのプレッシャーを軽減できると思います。

Nb。クラスからintプロパティだけを削除することで、エラーの発生を防ぐことができます。

ActionJava で、 3 つの int を保持するtype のオブジェクトを構築し、それを array 内の他のクラスに返すクラスを作成しようとしています。historyここhistoryで、 は type の配列ですAction。呼び出されると、すぐに無限ループになります。したがって、スタックオーバーフロー。

エラー - 1 行印刷しましたが、続きます...

クラス：

最近は、よりシンプルで再利用しやすい小さなオブジェクトを多数使用しています。ほとんどの場合、StructureMap (優れたツールです) を使用してこれらのオブジェクトを互いに挿入しても問題はありません。しかし、時々、私は失敗し、スタック オーバーフロー例外 (tm) を装って素敵な循環参照を取得します。

最後のテスト実行以降の最近の変更をすべて確認する以外に、StructureMap は循環参照をデバッグするためのメカニズムを提供していますか、またはこの状況で役立つ簡単なツールはありますか?

みんな、ありがとう！

XAMLまたはコードを介してファイルメニューのMenuItemにApplicationCommandsコマンドを追加すると、メニューを開くと、アプリケーションがスタックオーバーフローでクラッシュし、問題の詳細がまったくわかりません。コマンドを削除すると、問題も解消されます。どのApplicationCommandを使用するかは関係ありません。

コールスタックの一部：

• WindowsBase.dll！MS.Utility.ArrayItemList.ArrayItemList（int size）+0x20バイト
• WindowsBase.dll！MS.Utility.FrugalStructList.Capacity.set（int value）+0x6aバイト
• WindowsBase.dll！MS.Utility.FrugalStructList.FrugalStructList（int size）+0x9バイト
• PresentationCore.dll！System.Windows.EventRoute.EventRoute（System.Windows.RoutedEvent routedEvent）+0x35バイト
• PresentationCore.dll！System.Windows.EventRouteFactory.FetchObject（System.Windows.RoutedEvent routedEvent）+0x31バイト
• PresentationCore.dll！System.Windows.UIElement.RaiseEventImpl（System.Windows.DependencyObject sender = {System.Windows.Controls.RichTextBox}、System.Windows.RoutedEventArgs args = {System.Windows.Input.CanExecuteRoutedEventArgs}）+0x3fバイト
• PresentationCore.dll！System.Windows.UIElement.RaiseEvent（System.Windows.RoutedEventArgs args = {System.Windows.Input.CanExecuteRoutedEventArgs}、bool trusted）+0x35バイト
• PresentationCore.dll！System.Windows.Input.RoutedCommand.CriticalCanExecuteWrapper（オブジェクトパラメーター、System.Windows.IInputElementターゲット、boolトラステッド、System.Windows.Input.CanExecuteRoutedEventArgs args）+ 0x80バイト
  PresentationCore.dll！System.Windows.Input.RoutedCommand .CanExecuteImpl（object parameter = null、System.Windows.IInputElement target = {System.Windows.Controls.RichTextBox}、bool trusted = false、out bool continueRouting = false）+0x70バイト
• PresentationCore.dll！System.Windows.Input.RoutedCommand.CriticalCanExecute（オブジェクトパラメーター、System.Windows.IInputElementターゲット、boolトラステッド、out bool continueRouting）+0x3aバイト
• PresentationCore.dll！System.Windows.Input.CommandManager.TransferEvent（System.Windows.IInputElement newSource、System.Windows.Input.CanExecuteRoutedEventArgs e = {System.Windows.Input.CanExecuteRoutedEventArgs}）+0x52バイト
• PresentationCore.dll！System.Windows.Input.CommandManager.OnCanExecute（object sender、System.Windows.Input.CanExecuteRoutedEventArgs e）+ 0x8c bytes
  PresentationCore.dll！System.Windows.UIElement.OnCanExecuteThunk（object sender、System.Windows.Input。 CanExecuteRoutedEventArgs e）+0x44バイト
• PresentationCore.dll！System.Windows.Input.CanExecuteRoutedEventArgs.InvokeEventHandler（System.Delegate genericHandler、オブジェクトターゲット）+ 0x41バイト
  PresentationCore.dll！System.Windows.RoutedEventArgs.InvokeHandler（System.Delegateハンドラー、オブジェクトターゲット）+0x27バイトPresentationCore。 dll！System.Windows.RoutedEventHandlerInfo.InvokeHandler（object target、System.Windows.RoutedEventArgs routedEventArgs）+ 0x3e bytes
  PresentationCore.dll！System.Windows.EventRoute.InvokeHandlersImpl（object source = {System.Windows.Controls.RichTextBox}、System。 Windows.RoutedEventArgs args = {System.Windows.Input.CanExecuteRoutedEventArgs}、bool reRaised = false）+0x1bfバイト
• PresentationCore.dll！System.Windows.UIElement.RaiseEventImpl（System.Windows.DependencyObject sender = {System.Windows.Controls.RichTextBox}、System.Windows.RoutedEventArgs args =+0x79バイト
• PresentationCore.dll！System.Windows.UIElement.RaiseEvent（System.Windows.RoutedEventArgs args = {System.Windows.Input.CanExecuteRoutedEventArgs}、bool trusted）+0x35バイト
• PresentationCore.dll！System.Windows.Input.RoutedCommand.CriticalCanExecuteWrapper（オブジェクトパラメーター、System.Windows.IInputElementターゲット、boolトラステッド、System.Windows.Input.CanExecuteRoutedEventArgs args）+0x80バイト

アプリケーションが無限ループに陥っているようです。これは私のせいですか（そして何が間違っているのですか）、それとも.NET 3.5のバグですか？

私はこのコードを使用します：

コードまたはXAMLでmenuItemを作成するかどうかは関係ありません。また、前述したように、コマンドの設定もどこで行うかは関係ありません。MediaCommandsを使用する場合にも問題が発生するため、一般的にすべてのコマンドについて推測します。

RichTextBoxコード：

RichTextBoxは、TabItemから派生したコントロールのコンストラクターに追加されます。

スタックオーバーフローが発生し始めたとき、ここに来て質問する時が来たと思いました;）

ブーストスピリットの使い方を今勉強中です。基本的なことはわかりました。私は K&R (C の文法を含む) を手元に持っていたので、言語のアクセプターを作成できるかどうかを確認することにしました。とにかく、これは多かれ少なかれ私の当初の目標でした。最終的にはこれをプリプロセッサとして使用して、データ構造などから情報を収集したいからです。

定数と文字列を解析できますが、これを解析しようとすると問題が発生し始めます。

のようなものを渡すと、i++失敗します。これは がi有効であるため、またはprimary_expressionのチェックに進まないためだと思います。一番下に置いてみたところ、スタックオーバーフローが発生しました。ここで無限の左再帰が発生していますが、解決方法がわかりません。++--

スタック オーバーフロー エラーとは何ですか? どのタイプのプログラム/プログラミング言語で発生する可能性がありますか? Web アプリケーション コードで発生する可能性は低いですか?

問題を解決した唯一のことは、明示的なループでした:

私はフレックスが初めてで、サブアイテムのみがクリック可能なコンボボックスにアイテムとサブアイテムを作成する必要があります。http://blog.flexexamples.com/2007/09/25/creating-a-custom-combobox-item-renderer-in-flex/のように、指定されたリンクに示されているものと同様です が、ここではヘッダーとオプションの両方同時にクリックされますが、オプションのみをクリック可能にする必要があります 同じことを行う方法はありますか。助けてください。事前にサンクス。

私は、各ブラウザのすべての JavaScript 実装の詳細にあまり精通していません。ただし、setTimeout を使用すると、渡されたメソッドが別のスレッドで呼び出されることはわかっています。では、メソッド内で setTimeout を再帰的に使用すると、スタック オーバーフローが発生するまでそのスタックが無期限に拡大するのでしょうか? それとも、別のコールスタックを作成し、フォーカスが外れたら現在のフレームを破棄しますか? 気になるコーデはこちら。

サーバーを毎秒ポーリングしたいのですが、「ブロッキング ループ」で CPU サイクルを浪費したくありません。また、ユーザーがページにアクセスできる時間制限を設定したくありません。

編集

firebug を使用していくつかのブレークポイントを設定し、[スクリプト -> スタック] パネルを表示すると、コール スタックが文字通り単なる「pollServer」であり、コールごとに増加しないことがわかりました。これは良いことですが、JS の他の実装は異なる動作をしますか?