4

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

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

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

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

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

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

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

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

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

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

4

1 に答える 1

4

実行可能ファイルのスタックサイズを変更するために使用editbinできます。私の知る限り、app.configでこれを行うことはできません。

別のオプション（そのページにも記載されています）は、「適切な」スタックサイズで新しいスレッドを作成することです。このページでは、このアプローチの長所と短所について説明しています。

コンストラクターで400個のプロパティを設定するだけで問題が発生した場合は、驚きます...それは1つの大きなスタックフレームになります-しかし、スタックに複数の大きなスタックフレームがない限り、私はそれを期待します大丈夫です もう1つの可能性は、どこかで無限の再帰があることです:)

編集：別の提案...

おそらく、このコンストラクターには多くのローカル変数がありますか？（それ以外の場合は、他の呼び出しよりも多くのスタックを使用するべきではありません。）コンストラクターを複数のメソッドに分割して、メソッドごとに（たとえば）20フィールドを設定することは可能ですか？確かに、フィールドが読み取り専用の場合、これは注意が必要です。

コンストラクターがどのように見えるかを教えていただければ、それは大いに役立ちます。また、ildasmを使用して、そのコンストラクターのスタックサイズがどのようになるかを確認することもできます。

確認するだけで、これは構造体ではなくクラスですよね？

于 2009-06-25T05:48:17.720 に答える