Методы / инструменты для решения загадочного сбоя в сегменте во время работы на condor
https://stackoverflow.com/questions/3681755
-
02-10-2019 - |
italiano
english
français
española
中国
日本の
العربية
Deutsch
한국어
Português
RussianВопрос
Я пишу приложение на языке Си, которое запускается в вычислительном кластере (с использованием condor).Я перепробовал множество методов, чтобы выявить вредоносный код, но безрезультатно.
Подсказки:
- В среднем, когда я запускаю код на 15 машинах в течение 2 дней, я получаю два или три сбоя (сигнал 11).
- Когда я запускаю код локально, я не получаю segfault.Я запускал его почти 3 недели на своем домашнем компьютере.
Попытки:
- Я запускал код в valGrind в течение четырех дней локально без каких-либо ошибок памяти.
- Я зафиксировал сигнал segfault, определив свой собственный обработчик сигнала, чтобы я мог выводить часть состояния программы.
- Теперь, когда происходит сбой сегмента, я могу распечатать текущий стек, используя backtrace.
- Я могу распечатать значения переменных.
- Я создал переменную, для которой задан текущий номер строки.
- Также пробовал комментировать фрагменты кода, надеясь, что, если проблема исчезнет, я обнаружу ошибку segfault.
К сожалению, выводимый номер строки довольно случаен.Я не совсем уверен, что я могу сделать с трассировкой стека.Прав ли я, предполагая, что он записывает только адрес функции, в которой происходит ошибка segfault?
Подозрения:
- Я подозреваю, что система контрольных точек, которую condor использует для перемещения заданий между машинами, более чувствительна к повреждению памяти, и именно поэтому я не вижу ее локально.
- Что индексы повреждены из-за ошибки, и что эти индексы вызывают ошибку segfault.Это могло бы объяснить тот факт, что сбои в сегментах происходят при довольно случайных номерах строк.
Обновить
Изучив это еще немного, я нашел следующие ссылки:
Ошибка LibSegFault - библиотека для автоматического сбора и печати данных о состоянии segfaults.
Разматывание стека (трассировка стека) с помощью GCC учебное пособие по перехвату segfaults и получению номеров строк инструкций-нарушителей.
ОБНОВЛЕНИЕ 2
Грег предложил посмотреть журнал condor и "сопоставить ошибки segfaults с тем, когда condor перезапускает исполняемый файл с контрольной точки".Просматривая журналы, можно заметить, что все сбои происходят сразу после перезагрузки.По-видимому, все сбои возникают при переключении задания с одного типа машин на другой.
ОБНОВЛЕНИЕ 3
Ошибка segfault была вызвана различиями между хостами, установив поле 'requiremets' в файле отправки condor, чтобы проблема полностью исчезла.
Можно установить отдельные машины:
requirements = machine == "hostname1" || machine == "hostname2"
или целый класс машин:
requirements = classOfMachinesName
Смотрите пример требований здесь
Решение
если вы можете, скомпилируйте с помощью debugging и запустите под gdb.в качестве альтернативы, выгрузите ядро и загрузите его в отладчик.
mpich имеет встроенный отладчик, или вы можете купить коммерческий параллельный отладчик.
Затем вы можете пошагово просмотреть код, чтобы увидеть, что происходит в отладчике
Другие советы
Можете ли вы создать дамп ядра, когда произойдет ваш сбой segfault?Затем вы можете отладить этот дамп, чтобы попытаться определить состояние кода на момент его сбоя.
Посмотрите, какая инструкция вызвала неисправность.Была ли это вообще действительная инструкция или вы пытаетесь выполнить данные?Если это действительно так, к какой памяти он пытается получить доступ?Откуда взялся этот указатель?Вам нужно сузить область поиска вашей ошибки (повреждение стека, повреждение кучи, неинициализированный указатель, недопустимый доступ к памяти).Если это повреждение, посмотрите, есть ли какие-либо контрольные данные в поврежденной области (указатели на символы, данные, которые выглядят как что-то в ваших структурах, ...).Возможно, ваш распределитель памяти уже имеет встроенные функции для устранения некоторых повреждений (см. MALLOC_CHECK_ в Linux или MallocGuardEdges в Mac OS).Обычным случаем для них является использование памяти, которая была свободна (), поэтому регистрация ваших пар malloc() / free() может помочь.
Если вы использовали инструмент condor_compile для повторной привязки вашего кода к коду контрольной точки condor, он выполняет несколько действий иначе, чем обычная ссылка.Самое главное, что он статически связывает ваш код и использует свой собственный malloc.Еще одно большое отличие заключается в том, что condor затем запустит его на чужой машине, где среда может достаточно сильно отличаться от той, которая, как вы ожидаете, вызовет проблемы.
Исполняемый файл, сгенерированный condor_compile, может быть запущен как отдельный двоичный файл вне системы condor.Если вы запустите двоичный файл, отправленный из condor_compile локально, за пределами condor, вы все еще увидите ошибки segfaults?
Если это не так, можете ли вы соотнести ошибки segfaults с тем, когда condor перезапускает исполняемый файл с контрольной точки (журнал пользователя сообщит вам, когда это произойдет).
Ты перепробовал большую часть того, что я бы придумал.Единственное, что я бы еще посоветовал, это начать добавлять много кода ведения журнала и надеяться, что вы сможете сузить область возникновения ошибки.
Единственное, о чем вы не говорите, - это о том, насколько гибким вы должны быть, чтобы решить проблему.Можете ли вы, например, остановить систему и просто запустить свое приложение?Кроме того, насколько важно устранить эти сбои?
Я предполагаю, что по большей части вы так и делаете.Для этого может потребоваться много ресурсов.
Краткосрочный шаг состоит в том, чтобы поместить тонны "утверждений" (полу рукописных) каждой переменной чтобы убедиться, что она не изменилась, когда вы этого не хотите.Это может продолжать работать по мере прохождения долгосрочного процесса.
В долгосрочной перспективе - попробуйте запустить его на кластере из двух (возможно, на вашем домашнем компьютере и виртуальной машине ).Вы все еще видите ошибки в сегментах?Если нет, увеличивайте размер кластера до тех пор, пока не начнете видеть ошибки сегментирования.
Запустите его в минимальной конфигурации ( чтобы получить segfaults ) и запишите все ваши входные данные до сбоя.Автоматизируйте запуск системы с записанными вами входными данными, настраивая их до тех пор, пока вы не сможете постоянно получать сбой при минимальных входных данных.
В этот момент оглянитесь вокруг.Если вы по-прежнему не можете найти ошибку, вам придется запросить еще раз некоторые дополнительные данные, которые вы собрали в ходе этих запусков.
