Распределенная отладка программного обеспечения с помощью GDB
В настоящее время я занимаюсь разработкой распределенного программного обеспечения на C ++ с использованием Linux, которое выполняется более чем в 20 узлах одновременно. Итак, одна из самых сложных проблем, которые я обнаружил, — это как ее отладить.
Я слышал, что в одном сеансе GDB можно управлять несколькими удаленными сеансами (например, в главном узле я создаю сеанс GDB, а в каждом другом узле я запускаю программу с использованием GDB-сервера), возможно ли это? Если да, можете ли вы привести пример? Вы знаете другой способ сделать это?
Спасибо
Решение
Вы можете попробовать сделать это так:
Сначала запустите узлы с помощью gdbserver на удаленных хостах. Можно даже запустить его без программы для отладки, если вы запустите его с флагом —multi. Когда сервер находится в многорежимном режиме, вы можете управлять им из локального сеанса, я имею в виду, что вы можете заставить его запускать программу, которую вы хотите отлаживать.
Затем запустите несколько подчиненных в вашей сессии GDB
gdb> add-inferior -copies <number of servers>
переключите их на удаленную цель и подключите их к удаленным серверам
gdb> inferior 1
gdb> target extended-remote host:port // use extended to switch gdbserver to multi mode
// start a program if gdbserver was started in multi mode
gdb> inferior 2
...
Теперь у вас есть все они подключены к одной сессии GDB. Проблема в том, что, AFAIK, это не намного лучше, чем запускать несколько GDB с разных вкладок консоли. С другой стороны, вы можете написать несколько скриптов или автоматических тестов таким образом. Смотрите учебник GDB: сервер а также подчиненные.
Другие решения
Я не верю, что есть один простой ответ на отладку «многих удаленных приложений». Да, вы можете присоединиться к процессу на другом компьютере и выполнить его в GDB. Но довольно неудобно отлаживать большое количество взаимозависимых процессов, особенно когда проблема сложная.
Я считаю, что хороший набор возможностей ведения журнала в коде, дополненный дополнительными журналами для конкретной отладки по мере необходимости, с большей вероятностью даст вам хороший / быстрый результат.
Другим вариантом может быть запуск процессов на одном компьютере, а не на нескольких. Возможно даже использовать потоки внутри одного процесса, чтобы смоделировать поведение нескольких машин, упрощая процесс отладки. Конечно, это не предотвращает ошибки, возникающие ТОЛЬКО при запуске 20 процессов на 20 разных машинах. Но основная идея состоит в том, чтобы свести к минимуму количество этих ошибок и отладить большинство вещей в «более простой среде».
Агрессивное использование защитных парадигм программирования, таких как либеральное использование assert это, безусловно, хорошая идея (возможно, с макросом, чтобы отключить его для производственных запусков, но убедитесь, что вы не просто оставляете пути ошибок полностью непроверенными — гораздо труднее обнаружить, что причина чего-то дает сбой в том, что выделение памяти не удалось, чем отследить, откуда этот NULL-указатель поступил из примерно 20 вызовов функций после неудачного размещения.
detector