Лорчик, а как ты дебажишь race condition-ы в С++ коде?

пишу на Си 😎

Никак, я же не умею в многопоточные программы.

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

T, олсо тот случий, когда наблюдение аффктит на наблюдаемое.

-fsanitize=thread

ну и printf никто не отменял

man gdb

В любой непонятной ситуации начинай отладочную печать.

> valgrind --tool=helgrind

printf

Не буду оригинальным - printf.

Ну или std::cout, раз уж мы о плюсах говорим :)

std::printf

Из одного потока делаю printf'ы матов мужского рода, из другого - женского. Проще ловить баги - в процессе дебага в мозгу вырабатываются корректные матосочетания.

головой

Проектированием.

Где царь? Почему он ещё не высказался о том, что printf тормозит и меняет поведение потоков?

Обычно хватает анализа стектрейсов.

К сожалению printf и gdb не всегда успешны. Но вот дополнить их можно. Сам предпочитаю более активные методы отладки (обычно код оказвается чужой - кто его разберет, когда автор маньяк). Посему для особо злобных случаев не разбираемых статикой:

1. Использование дампа в память вместо printf (обычно аналогом дабы потом все было readable, т.е. указатель на формат + пачка параметров). Максимально корректная работа с кольцевым буфером дабы исключить наложения, некорректную историю и т.п. Обычный printf бывает сильно искажает картинку, что-то падает, но никакого отношения к конкретной проблеме не имеет. Хотя пару дней назад наблюдал как увеличивает вероятность падения (вот та ли причина?). Колечко также позволяет не ковыряться в огромной распечатке параллельных выводов, когда ошибка бывает раз в 8-15 часов. Главное суметь извлечь.

2. Добавление процедур, которые спопобны либо проверить консистентность текущего состояния, либо как минимум распечатать по максимуму все что нужно (и, в частности, кольцевой буфер).

3. Наличие возможности обращения к предыдущим процедупам по сигналам извне: запуск проверки из отладчика или как минимум установка/сброс флага сбора инфы из отладчика, периодический запуск средств проверки состояния/зависона/консистентности (аналогично по вводу, watchdog-у, посылке сигнала извне и т.п.).

4. Здравое недоверие (без фатальной паранои) к чужим thread save, SMP safe библиотекам. Вот заглянул позавчера в ассемблер одной и стало грустно - SMP uncompatible.

5. Иногда привычное действие (например, кажущееся очевидно атомарным, типа запись числа в память) так забавно искажается компилятором при определенных опциях. Или генерируется не signal-safe код.

6. А вообще это все настолько зависит от приложения ....

некая дебажная реализация мютексов с printf Starting lock, Finished lock , например. Если конечно в коде уже мютексы есть.

Доступ к данным, которые портятся, оборачивается в специальные Set/Get с printf-ами внутри отладочной инфы - процессID, тредID

printf тормозит

эдик может за него

Почему он ещё не высказался о том, что printf тормозит и меняет поведение потоков?

А разве не так?

Проектированием.

Люто, бешено плюсую. На этапе проектирования определить взаимодействие потоков и создать простые (т.е. очевидные) и безопасные интерфейсы для взаимодействия. И что-то я ниразу после этого не нарывался на гонки.

А чюжой код - вдумчивым разбором кода. Это быстрее, чем дебажиться.

Чужой код - он бывает разным. У меня один знакомый как-то наваял всего 5000 строк (для анализа - полная лафа) и в таком стиле, что как самому разумному, так и полному идиоту было ясно, что эта штука просто обязана работать. Без какой-либо параллельности. Никто ничего не смог найти без отладки - очевидно правильная библиотека, но изредка сбоила сволочь.

А это мизер на фоне текущих монстров с количеством строк в миллионы, объемом в гигабайты, временем сборки хорошо если в полдня, количеством процессов и нитей в сотни и временем до сбоя - дни. Ну и с выдачей sync чего-нибудь в значительной части файлов по grep.

Интересно сколько времени надо на вдумчивый разбор? Очевидно на невдумчивый очень много.

При этом автор одной из библиотек утверждает, что в его части некоторой ситуации быть в принципе не может. Есть доказательство. А тривиальный break показывает, что что-то в этом доказательстве не так, хотя блин и отработала несколько лет без единого сбоя.

делай логи и постмортемы

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

Статические анализаторы выдают предупреждения, если видят изменение переменной вне захваченной блокировки. Ориентируются на другие места, где блокировка захватывалась. У valgrind есть ещё инструмент drd, который тоже что-то там отлавливает, наряду с helgrind. Имеет смысл прогонять и под ним.

Если данные на стеке, можно использовать обёртку, которая в debug режиме использует malloc, а в release — alloca.

Сколько не писал многопоточного кода, рейсов написать не получалось. Наверное просто культура программирования.

Через внимательное ревью кода. gdb'ой, printf'ом и т.п. можно увидеть только какие-то простые случаи

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

В сложных случаях помогает только мысленная интерпретация кода.

В несколько потоков одновременно :) Если бы ещё код свой был, то куда ни шло

одноядерник тоже потоки не одновременно выполняет

а баг на многоядерниках только проявляется

valgrind --tool=helgrind

таки да

Плюсую. Сначала надо хорошо подумать и на бумажке всё расписать, от этого зависит около 85% успеха.

В любой непонятной ситуации начинай отладочную печать.

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

Расстрою проприетарщиной: Intel Inspector.

Именно, болезнь легче предотвратить, чем лечить.

Вот и отличненько, условие гонки не возникает - баг исправлен :)