Отладка распределенного программного обеспечения с gdb

Question

В настоящее время я разрабатываю распределенное программное обеспечение на C++ с использованием linux, которое выполняется более чем в 20 узлах одновременно. Поэтому одна из самых сложных проблем, которые я обнаружил, заключается в том, как отладить ее.

Я слышал, что можно управлять в одном сеансе gdb несколькими удаленными сеансами (например, в главном узле я создаю сеанс gdb и в каждом другом узле запускаю программу с помощью gdbserver), возможно ли это? Если да, то можете привести пример? Вы знаете какой-либо другой способ сделать это?

Благодаря

Answer 1

Вы можете попробовать сделать это так :

Первые стартовые узлы с gdbserver на удаленных хостах. Можно даже запустить его без отладки программы, если вы запустите ее с помощью --multi fl аги. Когда сервер находится в многорежимном режиме, вы можете управлять им из своего локального сеанса, я имею в виду, что вы можете запустить программу, которую вы хотите отлаживать. Затем запустите несколько подчиненных в вашей 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: server и inferiors.

Answer 2

Я не верю, что есть один, простой, ответ на отладку «много удаленных приложений». Да, вы можете подключиться к процессу на другом компьютере и выполнить его в GDB. Но неудобно отлаживать большое количество взаимозависимых процессов, особенно когда проблема сложная.

Я считаю, что хороший набор возможностей ведения журнала в коде, дополненный дополнительными журналами для конкретной отладки при необходимости, с большей вероятностью даст вам хороший/быстрый результат.

Другим вариантом может быть запуск процессов на одной машине, а не на нескольких машинах. Возможно, даже использовать потоки в рамках одного процесса, чтобы имитировать поведение нескольких машин, упрощая процесс отладки. Конечно, это не мешает ошибкам, которые появляются ТОЛЬКО при запуске 20 процессов на 20 разных машинах. Но основная идея - сократить количество этих ошибок до минимума и отладить большинство вещей в «более простой среде».

Агрессивное использование парадигм оборонительного программирования, таких как либеральное использование assert, является, пожалуй, хорошей идеей (возможно, с макросом, чтобы отключить его для производственных запусков, но убедитесь, что вы не просто оставляете пути ошибок полностью непроверенными - Намного сложнее обнаружить, что причина, по которой происходит сбой, заключается в том, что сбой памяти не удался, чем отследить, где указатель NULL пришел из примерно 20 вызовов функций от отказавшего выделения.