2016-06-03 4 views
2

У нас есть клиентское приложение .NET 4.0 WPF, которое загружается и выполняется на сотнях клиентских ПК/серверов ежедневно.Исключения .NET StackOverflow более вероятны на одном ПК

Мы недавно позвонили в нашу службу поддержки и сообщаем об ошибке с одной из наших процедур. При ближайшем расследовании я обнаружил, что эта машина кажется более склонной к возникновению исключения StackOverflow при выполнении одного из наших рекурсивных алгоритмов.

В качестве другой машины с точно такой же набор данных может завершить алгоритм с 30 рекурсивными итерациями, на этой машине он будет терпеть неудачу каждый раз, пока он не продвинется так далеко.

(1) Возможно ли, что определенная машина (или конфигурация ОС) с большей вероятностью столкнется с исключениями StackOverflow? Почему одна машина терпит неудачу до 30 итераций, а другая выходит за ее пределы? Что-то еще занимает место в «стеке»?

На, возможно, связанную с запиской, журнал ошибок этого же клиентом был заполнен «Недостаточно квот для обработки команды» исключение при попытке нажать на кнопках, открытых диалоговых окнах и т.д.

(2) Мог эти две ошибки указывают на общую причину?

ОС Windows Server 2012.

UPDATE: я наткнулся Why does a recursive call cause StackOverflow at different stack depths? и это, безусловно, выглядит, как это могло произойти. Я все еще не могу указать, какой параметр может вызвать это.

+0

Я думаю, что «много физической памяти» может быть относительно того, сколько бешенства работает на этой машине и занимает эту ОЗУ. – durbnpoisn

+0

Я действительно не понимаю, где происходит StackOverflow. Это код сервера или код клиента? Если это клиентский код, объем памяти на сервере не имеет значения. –

+0

Рекурсивный алгоритм - это клиентский код, но клиент (в данном случае) работает на машине серверного класса. –

ответ

3

Стек представляет собой ограниченный ресурс, вы можете захотеть просмотреть свой рекурсивный алгоритм с их конкретным набором данных, чтобы узнать, есть ли необычная проблема глубины рекурсии. Возможно, одна из их записей имеет круглую ссылку.

Объем доступной памяти не имеет подшипника. Размер стека по умолчанию для приложения .NET составляет 1 МБ. Если вы подозреваете, что вы только немного потеряли и не имеете круговой ссылки, вы можете использовать EDITBIN.EXE (https://msdn.microsoft.com/en-us/library/d25ddyfc.aspx), чтобы изменить размер стека сборки.

Если есть квоты памяти, вам необходимо будет просмотреть групповые политики, которые реализуют его для конкретного пользователя, имеющего проблему. Возможно, проблема заключается в неправильной конфигурации со стороны сервера.

+0

Что вы подразумеваете под «квотами памяти» и как это может повлиять? –

+0

На серверных ОС вы можете определить групповые политики, зависящие от пользователя и группы, определяющие квоты на диски и память. Возможно, квота памяти слишком низка для вашего приложения или пользователя, что станет источником ваших ошибок квот в вашем журнале. https://technet.microsoft.com/en-us/library/cc753446%28v=ws.11%29.aspx –