Советы по устранению трудно воспроизводимых ошибок параллелизма?

Question

Каковы некоторые советы по отладке, чтобы трудно воспроизвести ошибки параллелизма, которые происходят, скажем, только после каждой тысячи запусков теста? У меня есть один из них, и я не знаю, как его отладить. Я не могу помещать операторы печати или часы отладчика повсеместно, чтобы наблюдать за внутренним состоянием, потому что это изменило бы время и произвело бы огромное количество информации, когда ошибка не была успешно воспроизведена.

Answer 1

Вот мой метод: я обычно использую много assert (), чтобы проверять согласованность / достоверность данных как можно чаще.При сбое одного утверждения программа завершает работу, генерируя файл ядра.Затем я использую отладчик с основным файлом, чтобы понять, какая конфигурация потока привела к повреждению данных.

Answer 2

Это может не помочь вам, но, вероятно, поможет кому-то увидеть этот вопрос в будущем.

Если вы используете язык .Net, вы можете использовать проект CHESS из исследования Microsoft.Он запускает модульные тесты с каждым типом чередования потоков и показывает, какие из них вызывают ошибку.

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

Answer 3

Один метод для обнаружения повреждения данных, вызванного ошибкой параллелизма:

• Добавить атомный счетчик для этих данных или буфера.
  • Оставьте весь существующий код синхронизации как есть - не изменяйте их, предполагая, что вы собираетесь исправить ошибку в существующем коде, тогда как новый атомный счетчик будет удален после исправления ошибки.
• Когда вы начинаете изменять данные, увеличивайте атомный счетчик. Когда закончите, уменьшите.
• Дамп ядра, как только вы обнаружите, что счетчик больше единицы (используется что-то похожее на InterlockedIncrement)

Answer 4

Это сильно зависит от характера проблемы. Обычно полезны деление пополам (для сужения пространства поиска) + код «инструментария» с утверждениями для доступа к идентификаторам потоков, счетчиками блокировок / разблокировок, порядком блокировок и т. Д. В надежде, что когда проблема будет воспроизведена в следующий раз, приложение будет либо регистрировать подробное сообщение или дамп ядра с предложением решения.

Answer 5

Небольшая диаграмма, которую я сделал с некоторыми методами отладки, которые нужно учитывать при отладке многопоточного кода. Диаграмма растет, пожалуйста, оставляйте комментарии и советы для добавления. http://adec.altervista.org/blog/multithreading-debugging-chart/

Answer 6

Если ошибка является тупиковой, просто присоединяя инструмент отладки (например, gdb или strace) к программе после возникает тупик и наблюдая, где каждый поток застрял, часто можновам достаточно информации, чтобы быстро отследить источник ошибки.

Answer 7

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

Answer 8

Код целевого модульного теста отнимает много времени, но, по моему опыту, эффективен.

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