5.3, Трудные ошибки, нет зацепок

"Не за что зацепиться. Что происходит?" Если у вас действительно нет ни малейшей догадки о том, что же происходит, жизнь становится сложнее.

Сделайте ошибку воспроизводимой. Первый шаг — убедиться, что вы можете заставить ошибку проявляться по вашему желанию. Довольно угнетающе искать ошибку, которая появляется только время от време­ни. Потратьте время и найдите такую комбинацию входных данных и настроек, которые гарантированно приводят к ошибке, затем сделайте так, что эту ошибку можно было бы вызвать несколькими нажатиями клавиш. Если ошибка сложна, то при поиске проблемы вам придется по­вторять ее cнова и снова, поэтому, упростив воспроизведение ошибки, вы сэкономите свое время.

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

Если программа способна выдавать отладочную информацию, вклю­чите ее. Программа случайного моделирования, например программа markov из третьей главы, должна иметь ключ командной строки, выдаю­щий такую отладочную информацию, как, например, стартовое число генератора случайных чисел — это нужно для того, чтобы выдачу про­граммы можно было воспроизвести; другой ключ должен позволять устанавливать это стартовое значение. Многие программы имеют по­добные ключи командной строки, неплохо и вам сделать так же.

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

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

Изучайте нумерологию ошибок. Иногда определенная регулярность чисел, сопровождающих ошибку, подсказывает, на что нужно обратить внимание. Однажды в новой главе этой книги мы обнаружили серию опечаток, заключавшихся в пропадании случайных букв. Ситуация выглядела таинственной. Текст был создан посредством вырезания и вставки кусков другого файла, поэтому казалось, что проблемы были в этих самых командах вырезания и вставки. Откуда начать поиск? Мы взглянули на данные и заметили, что пропавшие символы были равномернораспределены по тексту. При измерении интервалов оказалось, что расстояние между пропавшими буквами было равно 1023 байтам — подозрительно круглое значение. Поиск в исходном тексте редактора нашел несколько кандидатов — чисел в районе 1024. Одно из этих чисел находилось в новом коде, поэтому мы исследовали именно его и немедленно обнаружили классическую "ошибку на единицу", где нулевой байт перезаписывал последний символ в 1024-байтовом буфере.

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

Выводите информацию, локализующую место ошибки. Если вы не по­нимаете, что именно делает программа, добавьте в нее операторы, отобра­жающие дополнительную информацию, — зачастую это самый простой и недорогой способ выяснения. Например, выведите в каком-нибудь мес­те кода "сюда нельзя добраться", если вы считаете, что это так; теперь, если вы увидите это сообщение, переместите операторы вывода назад, ближе к началу, чтобы выяснить, в каком месте начинается неправиль­ное поведение программы. Или же отображайте сообщение "добрались сюда", чтобы найти последнюю точку, в которой все еще было хорошо.

Сообщения должны отличаться друг от друга, чтобы можно было по­нять, куда именно вы смотрите.

Отображайте сообщения в компактной фиксированной форме, чтобы их можно было легко просматривать глазами или с помощью программ

типа grep. (Такие программы просто бесценны при поиске текста. В девятой главе приведена простая реализация такой программы.) Если вы отображаете значение переменных, форматируйте их одинаково. В С и C++ показывайте указатели в виде шестнадцатеричных чисел, напри­мер %х или %р; это поможет вам увидеть, равны ли два указателя, взаимо­связаны ли они. Научитесь читать значения указателей и распознавать возможные и невозможные значения, например ноль, отрицательные или нечетные числа, а также маленькие числа. Хорошее знакомство с ви­дами адресов поможет также при использовании отладчика.

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

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

/* check: проверить условие, напечатать сообщение */

/* и закончить работу */

void check(char *s)

{

if (var1 > var2) {

printf("%s: varl %d var2 %d\n", s, var~l, var2);

fflush(stdout); /* для гарантии выполнения вывода */ abort(); /* аварийное завершение */ }

}

}

Мы сделали так, что check вызывает abort, стандартную функцию библио­теки языка С, которая приводит к аварийному завершению работы про­граммы, чтобы затем можно было проанализировать ее с отладчиком. В каком-нибудь другом случае можно просто продолжить выполнение.

Теперь добавьте вызовы функции check везде, где она может быть по­лезна:

check("дo подозрительного места");

/* ... подозрительный код... */

check("после подозрительного места");

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

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

грамму до того, как возникнут какие-нибудь проблемы, чтобы их можно было просто включить в случае чего. Используйте их не только для отладки; пусть они будут включены на всех стадиях разработки программы. Если они не сильно влияют на производительность, будет разумно оставить их включенными навсегда. Большие программы типа систем телефонной коммутации часто отводят значительные куски кода "аудитным" подсистемам, которые регулярно анализируют информацию и оборудование, сообщают о встреченных ошибках или даже исправляют их.

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

[Sun Dec 27 16:19:24 1998]

HTTPd: access to /usr/local/httpd/cgi-bin/test.html

failed for m1.cs.bell-labs.com,

reason: client denied by server (CGI non-executable)

from http://m2.cs. bell-labs.com/cgi-bin/test.pi

Убедитесь, что вы сбрасываете буферы ввода-вывода, чтобы последние сообщения остались в журнальном файле. Функции вывода типа printf обычно буферизуют выводимые данные, чтобы делать вывод более эффективным; аварийное завершение приведет к потере

этих буферизованных данных. В языке С вызов функции fflush гаран­тирует, что все выводимые данные будут записаны до внезапного за­вершения программы; в C + + и Java существуют аналогичные функции для выходных потоков. Если вы хотите избежать лишней работы,

используйте для журнальных файлов небуферизованный ввод-вывод.

Стандартные функции setbuf и setvbuf управляют буферизацией; setbuf (fp, NULL) отключает буферизацию потока fp. Стандартные потоки сообщений об ошибке (stderr, cerr, System.err) обычно небуферизованы.

Постройте график. Иногда, при тестировании и отладке, картинки эф­фективнее, чем текст. Как мы увидели во второй главе, картинки особен­но полезны для понимания структур данных и, конечно же, при написа­нии программ работы с графикой, но они также могут использоваться для любых программ. Диаграммы разброса данных демонстрируют не­верные значения гораздо лучше, чем столбцы чисел. Гистограммы отра­жают странные места в экзаменационных оценках, случайных числах, размерах "корзин" операторов захвата памяти и хэш-таблиц и т. п.

Если вы не понимаете, что происходит в вашей программе, попро­буйте собрать статистику о структуре данных в ней и представить ре­зультаты графически. На приводимых графиках изображена статисти­ка цепочек в программе markov из главы 3: по оси х показана длина цепочек, а по оси у — количество элементов в цепочках этой длины. Входные данные — наш стандартный текст, Псалмы (42685 слов, 22482 префикса). Первые два графика соответствуют хорошим муль­типликаторам, 31 и 37, а третий — кошмарному мультипликатору 128. В первых двух случаях нет ни одной цепочки длиною больше 15 или 16, а большинство элементов хранится в цепочках из 5 или 6 элементов. В третьем случае область распределения много больше, самая длинная цепочка содержит 187 элементов, а в цепочках длиною больше 20 со­держатся тысячи элементов.⁸

Используйте различные инструменты. Используйте возможности сре­ды, в которой ведете отладку. Например, программа сравнения файлов, вроде diff, может сравнить результаты успешного и неуспешного за­пусков, чтобы вы сфокусировали внимание на том, что именно измени­лось. Если отладочная выдача очень длинна, используйте g rep для поиска в ней или текстовый редактор для ее исследования. Боритесь с желанием отправить отладочную выдачу на принтер: компьютеры обрабатывают объемистые данные гораздо лучше людей. Используйте языки скриптов и другие средства для автоматизации обработки вывода при отладочных запусках.

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

int main(void)

{

free(NULL);

return 0;

}

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

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