Как отлаживать программы, которые долго выполняются?
Есть некая программа, которая прерывается с сообщением об ошибке, например, через 2 часа после запуска. Сократить это время не как не могу, так как ошибка возникает только при выборе определённых параметров, которые и приводят к такой длительной работе.
За пару дней, записывая результаты каждого запуска в блокнот и потом анализируя результаты смог вычислить источник ошибки и исправить ошибку.
Но дело в том что бывают и такие программы которые выбрасывают ошибку через пару дней после запуска. Тогда отлаживать их вообще очень сложно. Пытался параллельно запускать несколько копий на нескольких компьютерах для того, чтобы ускорить получение результата и отладку. Но понял что меня это путает, ведь свой собственный анализ результата в голове всё равно будет последовательным.
Отсюда и вопрос. Не кто не знает о методах, приёмах, трюках для упрощения отладки программ, которые работают долго?
(повторюсь, что вопрос касается того случая когда уже нельзя сократить время работы)
Формальное доказательство и подробное логирование с разверткой стека.
Чуть больше паранойи при написании кода - проверять все входные параметры методов и процедур на допустимость, проверять возврат у всех системных обращений. Так ошибка найдется раньше.
Размещайте константы везде, где только возможно.
Собирайте с -Wall и добивайтесь отсутствия предупреждений.
1. Специальные условия выполнения. Например, у меня есть свой шаблон Array1d<>, в котором есть не только проверка диапазонов, но и т.н. «канарейка» — проверка, не испортила ли его случайно «сумасшедшая» подпрограмма. Все эти изыски включаются в параметрах компиляции.
2. Детальные логи ключевых объектов: что случилось и по какой причине.
3. Просто чутьё. Неинициализированную переменную на стеке я долго ловил: знал, где примерно ошибка, но любая диагностика (и даже перевод компилятора в debug) — стек смещается, и ищи ветра в поле. Включал проверку диапазонов, ту самую канарейку — ничего не даёт (ну естественно, никто и не пишет в «левую» память»). Много раз затыкал ошибку, но впоследствии я её как-то сумел продиагностировать, а дальше — дело техники.
Как вариант за первый запуск соорудить некоторое окружение из переменных и параметров, дабы получить картину. Затем спрограммировать хук - допустим что бы эти самые параметры можно было передавать в "ошибочную область" извне. Таким образом вы увеличите вероятность того что сами отловите ошибку без содействия программы - и пока она будет работать вы будете перебирать параметры пока сама программа не отвалиться. Уж там и можно будет понять - по вашей вине это произошло или нет.
Армянское Радио: можно написать тесты и для синхронизации, можно и для проверки на утечку ресурсов. Было бы желание/фантазия/время/ресурсы. Также не катит вариант, когда проект уже есть и архитектура у него плохо тестируемая и переписывать ради тестов проект никто не будет, или, возможно, платформа как-то ограничивает.
Написание тестов не отменяет детальное логгирование и все вышеуказанные советы, разумеется. Не панацея, не серебренная пуля. Но если они есть, и пишутся, и поддерживаются, то это +100500 к предсказуемости, уверенности в коде и painless дебаге, так как многие ситуации гораздо легче смоделировать.
> valgrind работает с отладочной версией программы Армянское Радио: отладочная информация нужна для полноты стектрейсов. Это означает, что при сборке нужно дать опцию -g компилятору и линковщику. Код программы при этом может быть "релизным" (-O2, NDEBUG, ...).
По части замедления в 50-100 раз я не уверен, мне кажется, что оно на порядок меньше.
Ждать. Если принять условие "ускорить процесс или эмулировать падение невозможно" - то включается максимальный уровень логирования, вставляются check-guard'ы везде, где только можно, коллстек пишется при любой ошибке (это несложно сделать изнутри, без дебагера). Все эксепшены обрабатываются в стиле - "это фатально, пишем колстек и вываливаемся". Ну и глазками по логам.
P.S. Всем, кто говорит, что нет ничего невозможного - у меня падал системный драйвер, причем причем ровно через 3 часа специфичной нагрузки. Не нормальный линуксовый, а блоб от производителя железки, ни о каких исходниках речи не шло. Около недели мы его обкладывали логами, везде, где только можно. Нашли. Но кровищи оно попило изрядно. Так что бывает так, что быстрее - не получится.
Простой
Простой
Простой
