OpenBSD Отчёты о проблемах


Отчёты о проблемах в выпущенных версиях (-release, -stable)

Прежде чем сообщать об ошибках/проблемах в выпущенных версиях, просмотрите этот контрольный список:

  1. Во-первых, проверьте есть ли исправления или какая-то информация, касающаяся релиза.
  2. Затем выясните, есть ли более новая версия OpenBSD.
  3. Наконец, просмотрите изменения между версиями OpenBSD.

Если из всего найденного ничто не относится к вашей проблеме, то, пожалуйста, ознакомьтесь с документацией о sendbug(1) прежде чем отправить отчет.

Отчёты о проблемах в -current

Если вы нашли проблему в -current, а не в -release или -stable, то

  1. Постарайтесь воспроизвести проблему по крайней мере дважды. При этом не сразу же раз за разом, но с периодичностью в несколько дней, при этом обноляясь (загружайте в течение этогого времени новый код из репозитория).
  2. Не сообщайте о проблемах связанных с компиляцией исходников. Почти всегда это либо ваша ошибка, либо о ней уже известно, и над ее исправлением уже работают. Люди, работающие над кодом проекта, запускают make build по крайней мере раз в день, и как правило по несколько раз в день на разных архитектурах.
  3. Помните, что синхронизация AnonCVS серверов отстает на несколько часов от сервера с исходниками, которыми пользуются разработчики.
  4. Проверьте изменения, внесенные уже после официального релиза, чтобы убедиться, что проблема была устранена.
  5. Большое внимание уделяется созданию снапшотов. Иногда происходят ошибки, и мы опаздываем с извинениями. Чтение или отправка письма в рассылку будет более разумным, чем отправка в отчете об ошибке.

Как создать хороший отчет о проблеме/ошибке

Всегда предоставляйте как можно больше информации. Попробуйте точно определить проблему. Дайте четкие пошаговые инструкции о том, как можно воспроизвести проблему. Постарайтесь описать её с максимально возможной точностью и не вводящей в заблуждение терминологией, особенно если ошибку нелегко воспроизвести. Описывать проблемы словами "it crashes" («это ломается») или "I get strange interrupt issues on this one box that I built" («наблюдаю странные проблемы с прерываниями на этом одной из собранных мной машин») бессмысленно. Пообщайтесь с другими пользователями (в списках рассылки или на любом другом форуме, где собираются опытные люди) и постарайтесь получить подтверждение, что проблема является новой и желательно воспроизводимой/повторяемой. Пожалуйста, убедитесь, что это не локальная проблема, возникающая по причине сломанного или неподдерживаемого оборудования или из-за использования неподдерживаемых параметров сборки или программного обеспечения.

Пожалуйста, не начинайте работать над исправлением проблем, которые требуют значительных временных затрат и усилий, если вы не уверены, что понимаете их. Особенно это касается кода, используемого в уже вышедьших релизах, где мы не должны изменять основные части кода. Если вы собираетесь работать над объемной частью кода, сообщите об этом нам в рассылке, чтобы все знали о ваших планах, и чтобы быть увененным, что никто другой уже не работает над этой же проблемой (чтобы исключить дублирования работы).

Следующая информация должна содержаться в каждом отчете:

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

  2. Вывод от команды, который вы получили. Пожалуйста, не говорите, что это «не сработало» или «не удалось». Если вы получили сообщение об ошибке, покажите его нам, даже если вы его не понимаете. Если ядро OpenBSD выбрасывает kernel panic, и вы видете ошибку, скажите нам об этом. Если ничего не происходит, скажите, что ничего не происходит. Даже если результатом описанных вами шагов является сбой программы или по-вашему мнению он очевиден, у нас может не получиться воспроизвести ошибку. Проще всего скопировать вывод с терминала, если это возможно.

    Примечание. В случае фатальных ошибок предоставленное сообщение об ошибке может содержать не всю доступную информацию. В этом случае просмотрите выходные данные в файлах системного журнала, например, хранящиеся в /var/log. Кроме того, если вы имеете дело с приложением, которое имеет свои собственные log-файлы, например httpd, проверьте наличие ошибок и там.

  3. Вывод ядра OpenBSD. Вы можете его увидеть при помощи команды dmesg, но возможно, что ваш вывод dmesg не будет содержать всей информации, которая содержится в /var/run/dmesg.boot. Если это так, покажите информацию оттуда и оттуда. Пожалуйста, всегда предоставляйте нам эту информацию при отправке отчетов.

  4. Если вы используете программное обеспечение, установленное из вне (third party software), которое так или иначе может быть связано с вашей ошибкой, скажите нам об этом, в том числе и её версию. Если речь идет о снапшоте, не забудьте сказать нам об этом. Важным тут является дата и время его создания.

  5. Traceback полученный в результате ошибки в ядре. Если в вашем ядре произошла ошибка, и вы получили приглашение ddb(4), то пожалуйста предоставьте panic message, а также вывод команд trace и ps в вашем отчете об ошибках. Если машина зависает, попробуйте сделать sysctl ddb.console = 1 до зависания и войти в DDB при помощи нажатия Ctl+Alt+Esc на клавиатуре (вы НЕ должны быть в графическом окружении) или отправить BREAK при использовании последовательной консоли (serial console). Если по какой-либо причине panic message не отображается, вы можете увидеть его при помощи команды show panic. Это важно, если это возможно. Отчеты о kernel panic без panic message, traceback и вывода комадны ps бессмысленны.. Также может быть интересным вывод show registers. Вам может потребоваться перезагрузка при помощи boot dump, чтобы образ ядра мог быть сохранен при помощи savecore(8) для последующей отладки, как описано на справочной странице crash(8).

  6. Если вы сообщаете о проблеме в X Window System для архитектуры, которая использует X.Org, то предоставьте нам содержание файлов /var/log/Xorg.0.log и dmesg.boot.

Не переживайте, если ваш отчет об ошибке получится довольно большим. Такова жизнь. Лучше сообщать обо всём сразу, чем нам потом вытягивать все необходимое из вас. С другой стороны, если ваши log-файлы огромны, то возможно стоит спросить, заинтересован ли в них кто-нибудь.

Отправка отчета об ошибке

Если это возможно, используйте команду sendbug(1) для создания отчета. Он автоматически добавит в отчет некоторую полезную информацию о вашем оборудовании, которая поможет диагностировать многие проблемы. Для использования этого инструмента требуется, чтобы ваша система могла правильно отправлять email. Если вы не можете использовать sendbug на работающем компьютере с OpenBSD, создайте отчет вручную и отправьте его на bugs@openbsd.org.

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

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