Spec-Zone .ru
спецификации, руководства, описания, API

1.7. Как Сообщить об Ошибках или проблемах

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

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

Нормальный способ сообщить об ошибках состоит в том, чтобы посетить http://bugs.mysql.com/, который является адресом для нашей базы данных ошибок. Эта база данных общедоступна и может быть просмотрена и искаться любым. Если Вы входите в систему к системе, можно ввести новые отчеты.

Ошибки, отправленные в базе данных ошибок в http://bugs.mysql.com/, которые исправляются для данного выпуска, отмечаются в информации о версии.

Если Вы находите чувствительную ошибку безопасности в MySQL Server, пожалуйста, сообщите нам сразу, отправляя электронное письмо . Исключение: клиенты Поддержки должны сообщить обо всех проблемах, включая ошибки безопасности, к Поддержке Oracle в http://support.oracle.com/.

Чтобы обсудить проблемы с другими пользователями, можно использовать один из списков рассылки MySQL. Раздел 1.6.1, "MySQL Mailing Lists".

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

Предпочтительно, следует протестировать проблему, используя последнюю версию производства или разработки MySQL Server перед регистрацией. Любой должен быть в состоянии повторить ошибку, только используя mysql test < script_file на Вашем прецеденте или выполняя оболочку или сценарий Perl, который Вы включаете в отчет об ошибках. У любой ошибки, которую мы в состоянии повторить, есть высокий шанс того, чтобы быть фиксированным в следующем выпуске MySQL.

Является самым полезным, когда хорошее описание проблемы включается в отчет об ошибках. Таким образом, дайте хороший пример всего, что Вы сделали, который привел к проблеме, и опишите, в точных деталях, проблема непосредственно. Лучшие отчеты - те, которые включают полный пример, показывающий, как воспроизвести ошибку или проблему. См. MySQL Internals: Портирование на Другие Системы.

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

Наиболее распространенные ошибки, сделанные в отчетах об ошибках, (a) не включая номер версии распределения MySQL, которое Вы используете, и (b), не полностью описывающий платформу, на которой сервер MySQL устанавливается (включая тип платформы и номер версии). Они - очень соответствующие сведения, и в 99 случаях из 100, отчет об ошибках бесполезен без них. Очень часто мы получаем вопросы как, "Почему это не работает на меня?" Затем мы находим, что опция, которую требуют, не была реализована в той версии MySQL, или что ошибка, описанная в отчете, была исправлена в более новых версиях MySQL. Ошибки часто зависимы от платформы. В таких случаях это почти невозможно для нас, чтобы фиксировать что-либо, не зная операционной системы и номера версии платформы.

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

Если программа производит сообщение об ошибке, очень важно включать сообщение в Ваш отчет. Если мы пытаемся искать что-то от архивов, лучше, что сообщение об ошибке, о котором сообщают точно, соответствует тот, который производит программа. (Даже lettercase должен наблюдаться.) Лучше копировать и вставлять все сообщение об ошибке в Ваш отчет. Никогда недопустимо пытаться воспроизвести сообщение из памяти.

Если у Вас есть проблема с Соединителем/ODBC (MyODBC), пожалуйста, попытайтесь генерировать файл трассировки и отправить его с Вашим отчетом. См. Раздел 21.1.8.2, "Как Сообщить о проблемах Соединителя/ODBC или Ошибках".

Если Ваш доклад включает в себя длинные выходные строки запроса от прецедентов, которые Вы выполняете с mysql инструментом командной строки, можно сделать вывод более читаемым при использовании --vertical опция или \G разделитель оператора. EXPLAIN SELECT пример позже в этом разделе демонстрирует использование \G.

Пожалуйста, включайте следующую информацию в свой отчет: