Здравствуйте, Kesular, Вы писали:

N>>Нет, скорее всего, это race condition в тестах. Иногда один поток модифицирует коллекцию, IEnumerator для которой в это время перебирается (с помощью MoveNext или foreach) в другом потоке. При изменении коллекции все живые энумераторы инвалидируются, и начинают бросать такое исключение.

K>Спасибо, Кэп, но есть одна небольшая проблема. В стек трейсе нет ни одного метода или класса, который не входит в FCL. А это значит, что коллекция принадлежит именно FCL.

Да, я и говорил про несинхронизированные коллекции из стандартной библиотеки. Они обладают таким свойством, как это и указано в документации. А тесты, видимо, используют их некорректным способом — модифицируют из одного потока, в то время как другой поток пытается перебирать их элементы.

Здравствуйте, Kesular, Вы писали:

N>>Нет, скорее всего, это race condition в тестах. Иногда один поток модифицирует коллекцию, IEnumerator для которой в это время перебирается (с помощью MoveNext или foreach) в другом потоке. При изменении коллекции все живые энумераторы инвалидируются, и начинают бросать такое исключение.

K>Спасибо, Кэп, но есть одна небольшая проблема. В стек трейсе нет ни одного метода или класса, который не входит в FCL. А это значит, что коллекция принадлежит именно FCL.

Да, я и говорил про несинхронизированные коллекции из стандартной библиотеки. Они обладают таким свойством, как это и указано в документации. А тесты, видимо, используют их некорректным способом — модифицируют из одного потока, в то время как другой поток пытается перебирать их элементы. Пользовательский код, видимо, выполняется в первом потоке, который модифицировал коллекцию, поэтому соовтветствующего стек-трейса не видно в исключении, которое возникло во втором потоке. Можно попробовать сохранять дамп процесса в момент возникновения исключение — возможно, потом в отладчике можно будет увидеть, с какой именно коллекцией возникает проблема.