Отчеты об ошибках в GDB
Ваши отчеты об ошибках играют существенную роль в обеспечении
надежности GDB.
Сообщение об ошибке может помочь вам найти решение вашей проблемы, а может и не помочь. Но в любом случае, основная функция отчета об ошибке---помочь всему обществу сделать следующую версию GDB лучше. Отчеты об ошибках---это ваш вклад в поддержку GDB.
Чтобы отчет об ошибке сделал свое дело, вы должны включить в него информацию, которая даст нам возможность ее устранить.
Вы нашли ошибку?
Если вы не уверены, нашли ли вы ошибку, вот несколько руководящих принципов:
- Если отладчик получает фатальный сигнал, то это ошибка в GDB, независимо от ввода. В надежных отладчиках сбоев не бывает.
- Если GDB выводит сообщение об ошибке для допустимого ввода---это ошибка. (Заметьте, что если вы выполняете кросс-отладку, проблема может возникать где-то в соединении к цели.)
- Если GDB не выводит сообщение об ошибке для недопустимого ввода, это ошибка. Однако вы должны обратить внимание, что если по вашему мнению что-то является "недопустимым вводом", по нашему мнению это может быть "расширением" или "поддержкой для традиционной практики".
- Если вы опытный пользователь средств отладки, ваши предложения по улучшению GDB приветствуются в любом случае.
Как составлять отчеты об ошибках
Некоторые компании и частные лица предлагают поддержку для программных продуктов GNU. Если вы получили GDB из организации поддержки, мы рекомендуем вам сперва связаться с ней.
Вы можете найти контактную информацию для многих организаций поддержки и частных лиц в файле `etc/SERVICE' в дистрибутиве GNU Emacs.
В любом случае, мы также рекомендуем вам послать отчет об ошибке в GDB по этому адресу:
<A HREF="mailto:bug-gdb@gnu.org">bug-gdb@gnu.org</A>
Не посылайте отчеты об ошибках в `info-gdb', или в `help-gdb', или в какую-либо группу новостей. Большинство пользователей GDB не хотят получать отчеты об ошибках. Те, кто этого действительно хочет, должны получать `bug-gdb'.
Список рассылки `bug-gdb' имеет группу новостей `gnu.gdb.bug', которая служит как повторитель. Список рассылки и группа новостей имеют в точности одинаковые сообщения. Часто люди посылают сообщения об ошибках в группу новостей, вместо отправки по электронной почте. Это работает, но имеется одна проблема, которая может быть решающей: группа новостей часто не имеет информации об обратном адресе отправителя. Таким образом, если нам потребуется запросить дополнительную информацию, мы можем не иметь возможности связаться с вами. По этой причине, лучше посылать отчеты об ошибках в список рассылки.
В крайнем случае, посылайте отчеты об ошибках на бумаге по адресу:
GNU Debugger Bugs Free Software Foundation Inc. 59 Temple Place - Suite 330 Boston, MA 02111-1307 USA
Основной принцип действенного составления отчетов об ошибках: сообщайте все факты. Если вы не уверены, оставить факт или исключить, оставьте его!
Часто люди опускают факты, потому что думают, что знают причины проблемы, и полагают, что некоторые детали не имеют значения. Таким образом, вы можете считать, что имя переменной, которую вы используете в примере, не имеет значения. Возможно это так, но нельзя быть уверенным в этом. Может быть ошибкой является неверное обращение к памяти, которое выбрало данные из ячеек, где хранилось это имя; возможно, если бы имя было другим, содержимое этих ячеек ввело бы отладчик в заблуждение, и ошибка не была бы замечена. Относитесь к этому осторожно, и приводите конкретные, полные примеры. Это самое простое что вы можете сделать, и наиболее полезное.
Помните, что цель отчета об ошибке состоит в том, чтобы дать нам возможность установить дефект. Может случиться, что об этой ошибке нам уже сообщали, но не вы, не мы не можем этого знать, если отчет об ошибке не будет полным и самодостаточным.
Иногда люди дают несколько поверхностных фактов и спрашивают, "не говорит ли это об ошибке?". Такие сообщения о дефектах бесполезны, и мы убеждаем всех отказываться отвечать на них, за исключением того, чтобы побудить автора отчета послать его правильно.
Чтобы дать нам возможность устранить ошибку, вы должны включить в сообщение следующее:
- Версию GDB. GDB сообщает ее при вызове без параметров; вы можете также вывести ее в любой момент, используя show version.
Без этого мы не будем знать, имеет ли смысл поиск ошибки в текущей версии отладчика.
- Тип машины, которой вы пользуетесь, название и номер версии операционной системы.
- Какой компилятор (и его версия) использовался при компиляции GDB. Например, "gcc--2.8.1".
- Какой компилятор (и его версия) использовался для компиляции отлаживаемой программы---например "gcc--2.8.1", или "HP92453-01 A.10.32.03 HP C Compiler". Для gcc, вы можете использовать gcc --version чтобы получить эту информацию; для других компиляторов, смотрите их документацию.
- Параметры команды, которые вы дали компилятору для компиляции вашего примера, с которым вы наблюдали ошибку. Например, использовали ли вы `-O'? Для гарантии, что вы не пропустите что-нибудь важное, перечисляйте все. Копии `Makefile' (или результата вызова make) достаточно.
Если мы должны будем угадывать аргументы, мы возможно сделаем это неправильно и можем не столкнуться с ошибкой.
Конечно, если ошибка состоит в получении GDB фатального сигнала, то мы, конечно, заметим это. Но если ошибкой является некорректный вывод, мы можем не заметить этого, если это не бросается в глаза. Вы также можете не дать нам возможности ошибиться.
Даже если ваша проблема заключается в фатальном сигнале, вы все же должны сообщить об этом явно. Предположим, происходит что-то странное, например, ваша копия GDB рассинхронизировалась, или вы столкнулись с ошибкой в библиотеке Си вашей системы. (Такое бывало!) Ваша копия может завершиться аварийно, а наша нет. Если вы предупредите нас об ожидаемой аварии, а в нашей системе этого не произойдет, мы будем знать, что ошибка произошла не из-за нас. Если вы нас не предупредите, мы не сможем сделать никаких выводов из наших наблюдений.
Номера строк в наших исходных текстах разработки не будут соответствовать вашим. Ваши номера строк не дадут нам никакой полезной информации.
Вот некоторые вещи, не являющиеся обязательными:
- Описание контекста ошибки.
Часто люди, сталкивающиеся с ошибкой, тратят много времени на исследования, какие изменения входного файла приведут к ее исчезновению, а какие на нее не влияют.
Это часто занимает много времени и приносит мало пользы, потому что мы найдем ошибку посредством выполнения одного примера под управлением отладчика с точками останова, а не чистыми выводами из серии примеров. Мы рекомендуем вам сохранить это время для чего-нибудь другого.
Конечно, если вы сможете найти более простой пример для отчета вместо первоначального, это будет удобнее для нас. Выделение ошибок в выводе будет проще, выполнение под управлением отладчика будет занимать меньше времени, и так далее.
Однако, это упрощение не является жизненно важным; если вы не хотите делать этого, сообщайте об ошибке в любом случае и посылайте нам весь тестовый материал, который вы использовали.
Заплата для исправления ошибки действительно поможет нам, если это хорошая заплата. Но не опускайте необходимую информацию, такую как тестовый пример, предполагая, что заплата это все, в чем мы нуждаемся. Мы можем обнаружить проблемы с вашей заплатой и решить устранить ошибку другим путем, или мы можем вообще не понять смысл вашей заплаты.
Иногда для такой сложной программы, как GDB, очень трудно создать пример, который заставит программу следовать по определенному пути в процессе выполнения. Если вы не пришлете нам пример, мы не сможем сконструировать его сами, и таким образом не сможем проверить, что ошибка устранена. И если мы не сможем понять, какую ошибку вы пытаетесь исправить, или почему ваша заплата являются улучшением, мы не используем ее. Тестовый пример поможет нам во всем разобраться.