Odkryliśmy, że jedno z naszych wygenerowanych automatycznie zestawów rzuca StackOverflowException w nowym (). Ta klasa ma (proszę ze mną współpracować) 400+ prostych właściwości, które są inicjowane (większość domyślnie (łańcuch) itp.) W konstruktorze.

Zauważamy, że świetnie działa na 64 bitach, ale na 32 bitach idzie hukiem!

Musimy przetestować, czy uzasadnione jest, aby nasz przypadek użycia stworzył większy domyślny stos, aby dać nam oddech, podczas gdy my modyfikujemy generator kodu.

Chcielibyśmy szczególnie. zainteresowani rozwiązaniami, które obejmują app.config, jeśli to możliwe. Ale jestem realistą, więc wszystko będzie dobrze.

Powody dla przepełnienia stosu. Zawęziliśmy błąd do danego konstruktora. Moje pierwsze wrażenia były również typu nieskończonej rekursji. Jednak powtórzyliśmy błąd przy użyciu 3-liniowej aplikacji konsoli, która:

tworzy pustą instancję klasy.wywołuje nie statyczną metodę (Clone) na klasie, której pierwszym zadaniem jest utworzenie i opróżnienie instancji gotowej do przekazania właściwości.

Szaleje, gdy uderza w drugiego konstruktora.

teraz debugując z kodem źródłowym .net widzimy, że przepełnienie stosu znajduje się w Guid.NewGuid (), który jest przekazywany jako drugi parametr do konstruktora. Rzeczywisty wiersz kodu to wywołanie natywnego wywołania CoCreateGuid ().

Chociaż może to być błąd w CoCreateGuid (), chcemy wyeliminować nasz kod z problemu. Moją pierwszą myślą jest masowe zwiększenie stosu i sprawdzenie, czy ten błąd się powtórzy. Następnie, ponieważ myślę, że możemy kontrolować wszystkie przypadki użycia, zastępujemy konstruktor inicjalizacją obiektu - myślę, że może to zmniejszyć nacisk na stos.

Nb. Możemy zatrzymać błąd, usuwając tylko własność int z klasy.