Linux программирование в примерах

Выбор того, как регистрировать сведения, является, конечно, легкой частью. Трудной частью является выбор того, что регистрировать. Как и в остальных случаях разработки программ, стоит подумать, прежде чем программировать. Записывайте сведения о критических переменных. Проверьте их значения, чтобы убедиться, что они в приемлемом диапазоне или в других отношениях ведут себя, как ожидается. Записывайте исключительные условия; если появляется что-то, что не должно было, зарегистрируйте это и при возможности продолжайте исполнение.

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

15.4.2.4. Файлы отладки времени исполнения

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

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

 struct stat sbuf;
 extern int do_logging; /* инициализировано нулями */

 if (stat("/path/to/magic/.file", &sbuf) == 0)
  do_logging = TRUE;
 ...
 if (do_logging) {
  /* здесь код журналирования: открытие файла, запись, закрытие и
  * т.д. * /
 }

Вызов stat происходил для каждого задания, которое выполняла программа. Таким образом, мы могли динамически включать и отключать журналирование без необходимости останавливать и повторно запускать приложение!

Как и в случае с отладочными опциями и переменными, в этом предмете имеется множество вариаций: различные файлы, которые запускают журналирование информации о различных подсистемах, директивы отладки, добавляемые в сам отладочный файл и т.д. Как и со всеми возможностями, следует планировать схему того, что вам будет нужно, а затем чисто ее реализовывать, вместо того, чтобы набросать какой-нибудь быстрый и грязный код в 3 часа пополудни (к сожалению, довольно типичная возможность в начинающих компаниях).

ЗАМЕЧАНИЕ. Не все то золото, что блестит. Специальные отладочные файлы являются лишь одним примером методик, известных как лазейки (back doors) — один или более способов выполнения разработчиками недокументированных вещей с программой, обычно с бесчестными намерениями. В нашем примере лазейка была исключительно доброкачественной. Но беспринципный разработчик легко мог бы устроить создание и загрузку скрытой копии списка клиентов, картотеки персонала или других важных данных. По одной этой причине вы должны серьезно подумать, применима ли эта методика в вашем приложении.

15.4.2.5. Добавьте специальные ловушки для контрольных точек

Часто проблема может быть воспроизводимой, но лишь после того, как программа сначала обработает многие мегабайты вводимых данных. Или, хотя вы и знаете, какая функция вызывает сбой, он возникает лишь после вызова этой функции сотни или даже тысячи раз.

Это большая проблема, когда вы работаете в отладчике. Если вы установите контрольную точку на вызывающую сбой процедуру, вам придется набирать команду continue и нажимать ENTER сотни или тысячи раз, чтобы привести программу в состояние перед сбоем. Это по меньшей мере утомительно и способствует появлению ошибок! Это может оказаться даже таким трудным, что вы захотите отказаться от этого, даже не начав.

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

Например, предположим, что вы знаете, что функция check_salary вызывает сбой, но лишь когда она вызвана 1427 раз. (Мы не смеемся над вами; в свое время нам пришлось наблюдать довольно странные вещи.)

Чтобы перехватить check_salary до того, как она завершится неудачей, создайте специальную фиктивную функцию, которая ничего не делает и просто возвращается, затем сделайте так, чтобы check_salary вызывала ее как раз перед 1427-м своим вызовом:

 /* debug_dummy --- отладочная функция-ловушка */
 void debug_dummy(void) { return; }

 struct salary *check_salary(void) {
  /* ...здесь описания настоящих переменных... */
  static int count = 0; /* для отладки */
  if (++count == 1426)
  debug_dummy;
  /* ...оставшаяся часть кода... */
 }

Теперь из GDB установите контрольную точку в debug_dummy, а затем запустите программу обычным способом:

 (gdb) break debug_dummy /* Установить контрольную точку для фиктивной функции */
 Breakpoint 1 at 0x8055885: file whizprog.c, line 3137.
 (gdb) run /* Запуск программы */

По достижении контрольной точки для debug_dummy вы можете установить вторую контрольную точку для check_salary и продолжить исполнение:

 (gdb) run /* Запуск программы */
 Starting program: /home/arnold/whizprog

 Breakpoint 1, debug_dummy at whizprog.c, line 3137
 3137 void debug_dummy(void) { return; } /* Достижение контрольной точки */
 (gdb) break check_salary
  /* Установить контрольную точку для интересующей функции */
 Breakpoint 2 at 0x8057913: file whizprog.c, line 3140.
 (gdb) cont

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

Вместо использования фиксированной константы ('++count == 1426') можно использовать глобальную переменную, которая устанавливается отладчиком в любое нужное вам значение. Это дает возможность избежать перекомпилирования программы

Для gawk мы пошли на один шаг дальше и внесли возможность отладочной ловушки в язык, так что функция ловушки могла быть вызвана из программы awk. При компилировании для отладки доступна специальная ничего не делающая функция stopme. Эта функция, в свою очередь, вызывает функцию С с тем же названием. Это позволяет нам поместить вызовы stopme в завершающуюся неудачей программу awk непосредственно перед сбойным участком. Например, если gawk выдает ошибочные результаты для программы awk в 1200-й вводимой записи, мы можем добавить в программу awk строку, подобную этой: