Здравствуйте, Kesular, Вы писали:
K>Время от времени, в интеграционных тестах возникает вот такое исключение:
K>
K>An unhandled exception of type 'System.InvalidOperationException' occurred in mscorlib.dll
K>Additional information: Collection was modified; enumeration operation may not execute.
K>Похоже, баг где-то во внутренностях фреймворка?
Нет, скорее всего, это race condition в тестах. Иногда один поток модифицирует коллекцию, IEnumerator для которой в это время перебирается (с помощью MoveNext или foreach) в другом потоке. При изменении коллекции все живые энумераторы инвалидируются, и начинают бросать такое исключение.
An enumerator remains valid as long as the collection remains unchanged. If changes are made to the collection, such as adding, modifying, or deleting elements, the enumerator is irrecoverably invalidated and the next call to MoveNext or Reset throws an InvalidOperationException.
The enumerator does not have exclusive access to the collection; therefore, enumerating through a collection is intrinsically not a thread-safe procedure. To guarantee thread safety during enumeration, you can lock the collection during the entire enumeration. To allow the collection to be accessed by multiple threads for reading and writing, you must implement your own synchronization.
Кроме рекомендуемой здесь ручной синхронизации, можно воспользоваться готовыми решениями из пространства имён System.Collections.Concurrent. См, например, ConcurrentBag.GetEnumerator():
The enumeration represents a moment-in-time snapshot of the contents of the bag. It does not reflect any updates to the collection after GetEnumerator was called. The enumerator is safe to use concurrently with reads from and writes to the bag.
Здравствуйте, nikov, Вы писали:
N>Нет, скорее всего, это race condition в тестах. Иногда один поток модифицирует коллекцию, IEnumerator для которой в это время перебирается (с помощью MoveNext или foreach) в другом потоке. При изменении коллекции все живые энумераторы инвалидируются, и начинают бросать такое исключение.
Спасибо, Кэп, но есть одна небольшая проблема. В стек трейсе нет ни одного метода или класса, который не входит в FCL. А это значит, что коллекция принадлежит именно FCL.
Здравствуйте, Kesular, Вы писали:
N>>Нет, скорее всего, это race condition в тестах. Иногда один поток модифицирует коллекцию, IEnumerator для которой в это время перебирается (с помощью MoveNext или foreach) в другом потоке. При изменении коллекции все живые энумераторы инвалидируются, и начинают бросать такое исключение.
K>Спасибо, Кэп, но есть одна небольшая проблема. В стек трейсе нет ни одного метода или класса, который не входит в FCL. А это значит, что коллекция принадлежит именно FCL.
Да, я и говорил про несинхронизированные коллекции из стандартной библиотеки. Они обладают таким свойством, как это и указано в документации. А тесты, видимо, используют их некорректным способом — модифицируют из одного потока, в то время как другой поток пытается перебирать их элементы. Пользовательский код, видимо, выполняется в первом потоке, который модифицировал коллекцию, поэтому соовтветствующего стек-трейса не видно в исключении, которое возникло во втором потоке. Можно попробовать сохранять дамп процесса в момент возникновения исключение — возможно, потом в отладчике можно будет увидеть, с какой именно коллекцией возникает проблема.
Здравствуйте, nikov, Вы писали:
N>Да, я и говорил про несинхронизированные коллекции из стандартной библиотеки. Они обладают таким свойством, как это и указано в документации. А тесты, видимо, используют их некорректным способом — модифицируют из одного потока, в то время как другой поток пытается перебирать их элементы. Пользовательский код, видимо, выполняется в первом потоке, который модифицировал коллекцию, поэтому соовтветствующего стек-трейса не видно в исключении, которое возникло во втором потоке. Можно попробовать сохранять дамп процесса в момент возникновения исключение — возможно, потом в отладчике можно будет увидеть, с какой именно коллекцией возникает проблема.
Я имею в виду коллекцию, которая создается и используется классами FCL, а не пользовательским кодом. В коде тестов есть пара коллекций, которые используются из разных потоков, но там с синхронизацией всё нормально.
Здравствуйте, Kesular, Вы писали:
K>Похоже, баг где-то во внутренностях фреймворка?
Весьма голословное утверждение. На StackOverflow такие вопросы сразу закрывают. Ну серьезно, перед тем как обвинять других, покажите код, в котором проблема воспроизводится, потратьте немного своего времени. Очень вероятно, что в попытках воспроизвести, вы сами локализуете проблемное место. См. mcve.
Здравствуйте, Sinix, Вы писали:
S>Неа, async void.
Похоже на то, есть там один такой метод. Но это всё равно баг, поскольку компилятор должен выдавать ошибку про невалидный код.
А не так, что ошибка благополучно игнорируется, пока не произойдет мутное исключение где-то в совсем другом месте.
Здравствуйте, Sinatr, Вы писали:
S>Весьма голословное утверждение. На StackOverflow такие вопросы сразу закрывают. Ну серьезно, перед тем как обвинять других, покажите код, в котором проблема воспроизводится, потратьте немного своего времени.
Там вообще закрывают и/или минусуют любые вопросы, которые выходят за уровень знаний обычной средней макаки с клавиатурой. Хоть трать своё время, хоть не трать.
Так что это не показатель.
Здравствуйте, Kesular, Вы писали:
K>Похоже на то, есть там один такой метод. Но это всё равно баг, поскольку компилятор должен выдавать ошибку про невалидный код.
Идея хорошая, только не компилятор, а аналайзер студии или решарпера. Если будет код с примером — можно будет джетбрейновцам предложение подкинуть.
K>А не так, что ошибка благополучно игнорируется, пока не произойдет мутное исключение где-то в совсем другом месте.
Ну так async void же. Какое ещё поведение у него должно быть?
P.S. А какая версия компилятора / target фреймворк, кстати? Смутно помнится, что от версии к версии поведение менялось.
Здравствуйте, Sinix, Вы писали:
S>Идея хорошая, только не компилятор, а аналайзер студии или решарпера. Если будет код с примером — можно будет джетбрейновцам предложение подкинуть.
Именно компилятор. Насколько я понимаю, async void вообще не имеет практического применения и всегда приводит к ошибкам, а отловить его — очень легко.
S>Ну так async void же. Какое ещё поведение у него должно быть?
Практически любое, кроме "что-то сломалось непонятно когда, непонятно где, непонятно почему, иди ищи причины в гугле".
S>P.S. А какая версия компилятора / target фреймворк, кстати? Смутно помнится, что от версии к версии поведение менялось.
Здравствуйте, Kesular, Вы писали:
K>Именно компилятор. Насколько я понимаю, async void вообще не имеет практического применения
Обработчики событий в UI.
K>и всегда приводит к ошибкам, а отловить его — очень легко.
Угу, вплоть до Async Void Methods Can Crash Your Process.
В общем, я бы заменил async void на async Task и подождал бы падения теста. Должно помочь. А, ну и убедиться, что pdb тестам доступны, по идее лог должен больше информации содержать.
Здравствуйте, Kesular, Вы писали:
S>>Неа, async void.
K>Похоже на то, есть там один такой метод. Но это всё равно баг, поскольку компилятор должен выдавать ошибку про невалидный код.
Возьмите анализаторы на будущее:
Здравствуйте, Sinix, Вы писали:
S>Угу, вплоть до Async Void Methods Can Crash Your Process. S>В общем, я бы заменил async void на async Task и подождал бы падения теста. Должно помочь. А, ну и убедиться, что pdb тестам доступны, по идее лог должен больше информации содержать.
Проблема не в том, что внутри метода произошло исключение — там все исключения ловятся на месте. Причина какая-то другая. И да, pdb доступны и стектрейс выше — абсолютно полный. Но замена на async Task каким-то образом подавляет эту проблему.
Здравствуйте, Kesular, Вы писали:
K>Проблема не в том, что внутри метода произошло исключение — там все исключения ловятся на месте. Причина какая-то другая. И да, pdb доступны и стектрейс выше — абсолютно полный. Но замена на async Task каким-то образом подавляет эту проблему.
Нету ручек — нет конфетки. В всмысле, нет воспроизводящейся ошибки — нет проблемы. Из спортивного интереса конечно можно накатать тест, который вызывает async void-метод, бросающий исключения, и попробовать поймать ошибку.
Но я бы не заморачивался, реальной необходимости в async void, как я понял, нет.
Здравствуйте, Sinix, Вы писали:
S>Из спортивного интереса конечно можно накатать тест, который вызывает async void-метод, бросающий исключения, и попробовать поймать ошибку.
