Обнаружение ошибки сегментации для многопоточной программы, работающей на кластере
Это довольно просто использовать gdb чтобы обнаружить ошибку сегментации при запуске простой программы в интерактивном режиме. Но учтите, что у нас есть многопоточная программа, написанная pthread — отправлено на узел кластера qsub команда). Таким образом, у нас нет интерактивной операции.
Как мы можем определить местонахождение ошибки сегментации? Я ищу общий подход, программу или инструмент тестирования. Я не могу привести воспроизводимый пример, так как программа действительно большая и в некоторых неизвестных ситуациях происходит сбой в кластере.
Мне нужно найти проблему в такой сложной ситуации, потому что программа работает правильно на локальной машине с любым количеством потоков.
Решение
«Нормальный» подход состоит в том, чтобы окружение создавало основной файл и получало его. Если это не вариант, вы можете попробовать установить обработчик сигнала для SIGSEGV который получает, по крайней мере, трассировку стека, где-то сброшенную. Конечно, это сразу приводит к вопросу «Как получить трассировку стека» но это ответ в другом месте.
Самый простой подход — это, вероятно, получить основной файл. Предполагая, что у вас есть аналогичный компьютер, на котором можно прочитать основной файл, вы можете использовать gdb program corefile отлаживать программу program который произвел основной файл corefile: Вы должны иметь возможность просматривать различные потоки, их данные (в некоторой степени) и т. Д. Если у вас нет подходящей машины, может потребоваться перекрестная компиляция gdb соответствие аппаратного обеспечения машины, на которой он был запущен.
Меня немного смущает утверждение, что файлы ядра пусты: вы можете установить ограничения для файлов ядра, используя ulimit на оболочке. Если размер ядер установлен равным нулю, он не должен создавать файл ядра. Создание пустого кажется странным. Однако, если вы не можете изменить ограничения в вашей программе, вы, вероятно, должны установить обработчик сигнала и вывести трассировку стека из потока-нарушителя.
Подумав об этом, вы можете перевести программу в спящий режим в обработчике сигналов и подключиться к нему с помощью отладчика, предполагая, что вы можете запустить отладчик на соответствующей машине. Вы бы определили идентификатор процесса (например, используя ps -elf | grep program), а затем прикрепить к нему с помощью
gdb program pid
Я не уверен, как положить программу для сна изнутри программы (возможно, установка обработчика для SIGSTOP за SIGSEGV…).
Тем не менее, я полагаю, вы пытались запустить вашу программу на локальном компьютере …? Некоторые проблемы более фундаментальны, чем необходимость в распределенной системе из множества потоков, работающих на каждом узле. Это, очевидно, не замена для подхода выше.
Другие решения
Других решений пока нет …