LINUX.ORG.RU

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

 , , ,


1

3

Сабж. Поделитесь историями успеха и неуспеха

P.S. Для всяких умников с проектированием и культурой программирования - код не мой

★★★★★

Последнее исправление: Harald (всего исправлений: 1)

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

hlebushek ★★
()

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

yoghurt ★★★★★
()
Ответ на: комментарий от yoghurt

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

anonymous
()

-fsanitize=thread

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

AF ★★★
()

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

mtk
()

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

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

nanoolinux ★★★★
()

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

crowbar
()

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

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

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

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

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

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

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

io ★★
()
Последнее исправление: io (всего исправлений: 2)

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

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

Deleted
()
Ответ на: комментарий от nanoolinux

printf тормозит

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

anonymous
()
Ответ на: комментарий от nanoolinux

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

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

nerdogeek
()
Ответ на: комментарий от nanoolinux

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

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

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

Pavval ★★★★★
()
Ответ на: комментарий от Pavval

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

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

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

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

io ★★
()
Последнее исправление: io (всего исправлений: 1)

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

qulinxao ★★☆
()

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

anonymous
()

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

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

i-rinat ★★★★★
()

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

slovazap ★★★★★
()

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

mashina ★★★★★
()

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

amaora ★★
()
Ответ на: комментарий от amaora

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

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

Harald ★★★★★
() автор топика
Ответ на: комментарий от anonymous

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

Harald ★★★★★
() автор топика
Ответ на: комментарий от anonymous

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

peregrine ★★★★★
()
Ответ на: комментарий от anonymous

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

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

x_hash
()
Ответ на: комментарий от x_hash

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

stevejobs ★★★★☆
()
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.