Методы / Инструменты для решения Mystery Segfault при работе на кондоре

Question

Я пишу C-приложение, которое запускается на вычислительном кластере (используя condor). Я перепробовал много способов, чтобы выявить код, который нарушил работу, но безрезультатно.

Улика:

• В среднем, когда я запускаю код на 15 машинах в течение 2 дней, я получаю два или три ошибки по умолчанию (сигнал 11).
• Когда я запускаю код локально, у меня не возникает ошибка по умолчанию. Я управлял им почти 3 недели на моей домашней машине.

Попытка:

• Я запускал код в valGrind в течение четырех дней локально, без ошибок памяти.
• Я перехватил сигнал segfault, определив свой собственный обработчик сигнала, чтобы я мог выводить часть состояния программы.
• Теперь, когда произошла ошибка, я могу распечатать текущий стек, используя обратную трассировку.
• Я могу распечатать значения переменных.
• Я создал переменную, для которой задан текущий номер строки.
• Также пытались комментировать фрагменты кода, надеясь, что если проблема исчезнет, ​​я обнаружу ошибку segfault.

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

Подозрения:

• Я подозреваю, что система контрольных указателей, которую использует кондор для перемещения заданий по машинам, более чувствительна к повреждению памяти, и поэтому я не вижу ее локально.
• То, что индексы искажены ошибкой, и что эти индексы вызывают ошибку по умолчанию. Это объяснило бы тот факт, что segfaults происходят на довольно случайных номерах строк.

UPDATE

Исследуя это, я нашел следующие ссылки:

• LibSegFault - библиотека для автоматического перехвата и печати данных о состоянии ошибок сегментов.

• Разматывание стека (трассировка стека) с помощью учебника по GCC по отлову ошибок сегмента и получению номеров строк ошибочных инструкций.

ОБНОВЛЕНИЕ 2

Грег предложил взглянуть на журнал кондора и «сопоставить ошибки, с которыми кондор перезапускает исполняемый файл с контрольной точки». Глядя на логи, все ошибки segfaults происходят сразу после перезапуска. Все сбои возникают, когда задание переключается с одного типа компьютера на другой тип.

ОБНОВЛЕНИЕ 3

Ошибка произошла из-за различий между хостами, поскольку поле 'requiremets' в файле подтверждения condor полностью исчезло.

Можно установить отдельные машины:

requirements = machine == "hostname1" || machine == "hostname2"

или целый класс машин:

requirements = classOfMachinesName

См. Пример требований здесь

Answer 1

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

mpich имеет встроенный отладчик, или вы можете купить коммерческий параллельный отладчик.

Затем вы можете просмотреть код, чтобы увидеть, что происходит вотладчик

http://nmi.cs.wisc.edu/node/1610

http://nmi.cs.wisc.edu/node/1611

Answer 2

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

Посмотрите, какая инструкция вызвала ошибку.Была ли это действительная инструкция или вы пытаетесь выполнить данные?Если он действителен, к какой памяти он пытается получить доступ?Откуда этот указатель?Вам необходимо сузить местоположение вашей ошибки (повреждение стека, повреждение кучи, неинициализированный указатель, доступ к неверной памяти).Если это искажение, посмотрите, есть ли какие-либо контрольные данные в поврежденной области (указатели на символы, данные, которые выглядят как что-то в ваших структурах, ...).Возможно, ваш распределитель памяти уже имеет встроенные функции для отладки некоторых повреждений (см. MALLOC_CHECK_ в Linux или MallocGuardEdges в Mac OS).Распространенным случаем для этого является использование памяти, которая была свободна () 'd, поэтому регистрация ваших пар malloc () / free () может помочь.

Answer 3

Если вы использовали инструмент condor_compile, чтобы связать свой код с кодом контрольной точки condor, он делает несколько вещей иначе, чем обычная ссылка.Самое главное, что он статически связывает ваш код и использует свой собственный malloc.Еще одно большое отличие состоит в том, что condor затем запустит его на чужой машине, где среда может достаточно отличаться от того, что вы ожидаете вызвать проблемы.

Исполняемый файл, сгенерированный condor_compile, запускается как отдельный двоичный файл внесистема кондора.Если вы запускаете двоичный файл, испускаемый из condor_compile локально, вне condor, вы все еще видите segfaults?

Если это не так, можете ли вы соотнести segfaults с тем, когда condor перезапускает исполняемый файл с контрольной точки (пользовательжурнал сообщит вам когда это произойдет).

Answer 4

Одна вещь, которую вы не говорите, это то, насколько гибко вы должны решить проблему.Можете ли вы, например, остановить систему и просто запустить приложение?Также насколько важны эти сбои для решения?

Я предполагаю, что по большей части вы делаете.Это может потребовать большого количества ресурсов.

Краткосрочный шаг состоит в том, чтобы поместить тонны «утверждений» (частично рукописных) каждой переменной, чтобы убедиться, что она не изменилась, когда вы этого не хотите.Это может продолжать работать, когда вы проходите через длительный процесс.

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

Запустите его на минимальной конфигурации (чтобы получить ошибки сегмента) и запишите все ваши входные данные до сбоя.Автоматизируйте работу системы с записанными вами входами, настраивая их до тех пор, пока вы не добьетесь последовательного сбоя с минимальным вводом.

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

Answer 5

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