2.3 Comment rapporter des bugs et des problèmes

Ecrire un rapport de bug nécessite de la patience, mais ce premier geste va économiser votre temps, et le notre. Cette section vous aide à écrire votre rapport de bug correctement, de manière à ce que vous ne perdiez pas votre temps à écrire des messages qui ne nous servirons à rien.

Nous vous encourageons à utiliser le script mysqlbug pour générer un rapport de bug (ou un rapport sur n'importe quel problème). mysqlbug est situés dans le dossier de la distribution source, ou, dans la distribution binaire, dans le dossier `bin' de votre dossier d'installation MySQL.Si vous ne pouvez pas utiliser mysqlbug, il est préférable d'inclure toutes les informations listées ci dessous.

Le script mysqlbug vous aide à générer un rapport de bug en déterminant les informations suivantes automatiquement : mais si vous pensez que quelque chose d'important manque, ajoutez le au message. Relisez attentivement cette section, et assurez vous que toutes les informations décrites ci dessous sont incluses dans votre rapport.

Gardez à l'esprit qu'il est toujours possible de répondre à un message qui contient trop d'information, alors que ce n'est pas possible avec un message qui en contient pas assez. Souvent, les rapports omettent des informations car les utilisateurs pensent avoir compris les causes du problème et que certains détails sont insignifiants. Le bon principe est le suivant : Si vous doutez de quelque chose, dites le. Il est milles fois plus rapide d'ajouter quelques lignes dans votre rapport, plutôt que d'être forcé de le renvoyé encore une fois, pour complément d'information.

L'erreur la plus répandue est que les utilisateurs n'indique pas le numéro de version de la distribution MySQL qu'ils utilisent, ou la plate forme sur laquelle ils opèrent (y compris la version de cette plate forme). C'est une information primordiale, et 99% des cas sont inexploitables sans cette information. Souvent, nous avons des questions du genre : ``Pourquoi est ce que ça plante chez moi?'' et nous nous aperçevons que cette fonctionnalité n'est pas disponible sur la version de MySQL utilisée, ou bien que le bug a été corrigé dans les versions plus récentes. Parfois, l'erreur dépend de l'OS. Dans ces cas, il est presque impossible de corriger l'erreur sans connaitre le nom de l'OS, et le numéro de version de la plate forme.

N'oubliez pas d'inclure des inforamtions sur les compilateurs, si cela a un rapport avec votre problème. Souvent, on trouve des erreurs dans les compilateurs, et les utilisateurs pensent que c'est lié à MySQL. La plus part des compilateurs sont en développement constants, et s'améliorent de version en version. Pour savoir si votre problème dépend du compilateur, nous avons besoin de savoir quel compilateur est utilisé. Notez que chaque problème lié à la compilation doit être considéré comme un bug, et rapporté de manière adéquate.

Une bonne description du problème est toujours utile dans un rapport de bug. C'est à dire, toutes les manipulations que vous avez faites, qui ont conduit au bug, et la description du bug lui même. Les meilleurs rapports inclus aussi un exemple complet pour reproduire le bug.

Si un programme produit un message d'erreur, il est très important d'inclure le message dans votre rapport! Si vous recherchez dans les archives, il est préférable d'utiliser le message d'erreur exact (même la casse est importante). N'essayez pas de vous souvenir du message : faites en un copier/coller du message entier!

Pensez à inclure les informations suivantes dans votre rapport:

  • Le numéro de version de la distribution de MySQL que vous utilisez (par exemple, MySQL 3.22.22). Vous pouvez savoir le numéro de version que vous utilisez en exécutant la commande mysqladmin version. mysqladmin est situé dans le dossier `bin' de votre dossier d'installation MySQL.
  • La marque et le modèle de machine que vous exploitez.
  • Le nom de l'OS et sa verison. Pour la plus part des OS, vous pouvez avoir ces informations avec la commande UNIX uname -a.
  • Parfois, la quantité de mémoire (réelle et virtuelle) est importante. En cas de doute, incluez ces valeurs.
  • Si vous utilisez une version source de MySQL, le nom et la version du compilateur est aussi apréciable. Si vous avez une version binaire, le nom de la distribution est nécessaire.
  • Si le problème intervient lors de la compilation, incluez l'erreur exacte, le message d'erreur, et quelques lignes de contexte.
  • Si une table est liée au problème, incluez le résultat de la commande mysqldump --no-data nom_base_de_donnees nom_table1 nom_table2 ... C'est très simple à faire, et c'est une méthode puissante pour rassembler toutes les informations d'une table qui nous permettra de recréer une situation identique à la votre.
  • Pour les bugs liés à la vitesse, ou les problèmes avec les commandes SELECT vous devriez toujours include le résultat d'une commande EXPLAIN SELECT ..., et au moins le nombre de lignes que votre commande SELECT doit produire. Plus vous pourrez transmettre d'informations, sur votre situation, plus nous pourrons vous aider. Par exemple, voici un très bon rapport de bug ( posté avec le script mysqlbug, bien entendu) : Exemple lancé depuis la ligne de commande mysql: 
    mysql> SHOW VARIABLES;
mysql> EXPLAIN SELECT ...
       <output-from-EXPLAIN>
mysql> FLUSH STATUS;
mysql> SELECT ...
       <Une courte description du résultat de SELECT,
       en incluant le temps de travail de la requête>
mysql> SHOW STATUS;
       <output from SHOW STATUS>
  • Si un bug ou un problème intervient lors du fonctionnement de MySQL, essayer de nous fournir un script qui pourra reproduire l'anomalie. Ce script incluera tous les fichiers nécessaires. Plus le script sera proche de votre environnement, et mieux ce sera. Si vous ne pouvez pas fournir de script, vous devez au moins nous fournir l'affichage de mysqladmin variables extended-status processlist dans votre mail, pour nous fournir des informations sur votre système.
  • Si vous pensez que MySQL produit un résultat un peu inattendu, pensez à inclure non seulement l'étrange résultat de votre requête, mais aussi votre avis sur ce qui devrait être retourné, et ce qui le justifie.
  • Lorsque vous donnez un exemple de problème, il est mieux d'utiliser des noms de variables, de tables, qui existent dans votre situation réelle, plutôt que d'inventer de nouveau noms. Le problème peut être lié aux noms de colonnes, table...etc! Ces cas sont peut être rares, mais il vaut mieux être prudent que navré. Après tout, il est plus facile de fournir un exemple proche de votre exemple et c'est aussi plus clair pour nous. Dans le cas où vous ne souhaitez pas afficher vos données à des tiers, vous pouvez utiliser le dossier ftp pour le transférer : ftp://www.mysql.com/pub/mysql/secret/. Si les données sont vraiment très confidentielles, et que vous ne voulez pas nous les montrer, utilisez d'autres valeurs, mais considérez ce choix en dernier recours!
  • Incluez toutes les options utilisées par les programmes adéquats, si possible. Par exemple, vous pouvez indiquer les options de démarrage de mysqld, et celle que vous utilisez pour les clients MySQL. Les options de programmes tels que mysqld et mysql, et le script configure sont souvent la clé de mystères. Ce n'est jamais une mauvaise idée de nous les transmettre, de toutes manières. Si vous utilisez des modules, tels que Perl ou PHP, n'oubliez pas de donner leur numéro de version.
  • Si vous n'arrivez pas à reproduire l'erreur avec quelques lignes, ou que la table est trop grosse pour être postée sur la liste de diffusion (plus de 10 lignes), il est préférable de faire un dump de la table, avec mysqldump et de créer un fichier `README' qui décrit votre problème. Créez une archive compressée de vos fichiers avec tar et gzip ou zip, et transférez en ftp dans le dossier ftp://www.mysql.com/pub/mysql/secret/. Puis, envoyez une courte description de votre problème sur la liste de diffusion.
  • Si vos questions sont liées aux droits, ajoutez les données de mysqlaccess, celui de mysqladmin reload et tous les messages d'erreur que vous obtenez en vous connectant. Lorsque vous testez les droits, il est préférable de faire tourner d'abord mysqlaccess. Après ça, excécutez la commande mysqladmin reload version, et en dernier ressort, essayez de vous connectez avec le programme qui pose problème. mysqlaccess est situé dans le dossier `bin' de votre dossier d'installation.
  • Si vosu avez un patch pour un bug, c'est bien. Mais ne supposez jamais que ce patch est tout ce dont nous révions, ou même que nous allons l'utiliser si vous ne fournissez pas les informations nécessaires pour tester le bug. Nous pouvons rencontrer des problèmes avec votre patch, voire même, nous pouvons ne pas le comprendre. Dans ce cas, nous ne pourrons pas l'utiliser. Si nous ne pouvons pas vérifier l'objectif du patch, nous ne l'utiliserons pas. Les cas de tests nous seront d'un précieux secours. Montrez bien toutes les situations que le patch prend en compte. Si nous trouvons un effet de bord (même rare), ou un cas extrême que le patche ne gère pas, il risque d'être inutile.
  • Toutes les tentatives de deviner l'origine du bug, pourquoi il survient, ou de quoi il découle sont généralement fausses. Il arrive que même nous, avec l'aide d'un débugger, ne pouvons pas toujours determiner la cause réelle du bug.
  • Indiquez dans votre mail que vous avez vérifié le manuel de référence, et les archives, de manière à montrer que vous avez déjà essayé de résoudre le problème vous même.
  • Si vous avez une erreur parse error, prenez le temps de bien vérifier votre syntaxe. Si vous ne pouvez pas trouver d'erreur, il est fort probable que votre version de MySQL ne supporte par la requête que vous utilisez. Si vous utilisez la version courant et que le manuel de référence http://www.mysql.com/doc.html ne couvre pas la syntaxe que vous utilisez, c'est que MySQL ne supporte pas votre requête. Dans ce cas, votre seul option est d'implémenter vous même l'option ou d'envoyer un email à mysql-licensing@mysql.com et demandez à ce qu'elle soit implémentée. Si le manuel couvre votre syntaxe, mais que vous avez une vieille version de MySQL, vérifiez l'historique de MySQL pour voir quand la syntaxe a été implémentée. D Historique des versions de MySQL. Dans ce cas, il vous reste la possibilité de vous mettre à jour avec une nouvelle version de MySQL.
  • Si vous avez un problème tel que vos données semblent corrompues, ou que vous avez des erreurs lorsque vous accédez à une table particulière, vous devriez essayer de vérifier et réparer vos tables avec isamchk. 13 Maintenance d'un serveur MySQL.
  • Si vos tables se corrompent souvent, vous pouvez essayer de voir quand cela arrive, et pourquoi! Dans ce cas, `mysql-data-directory/'hostname'.err' peut contenir certaines informations sur ce qui est passé. N'oubliez pas d'ajouter toutes les informations utiles dans votre rapport de bug. Normalement, mysqld ne crashe JAMAIS de table s'il n'a pas été tué durant une modification. Si vous pouvez trouver la source de la fin du processus mysqld, il est plus facile pour nous de vous fournir un correctif.
  • Si possible, téléchargez la version la plus récente de MySQL et vérifiez si cela résoud votre problème. Toutes les versions de MySQL sont testés de manière exhaustive, et devrait fonctionner sans problème. Nous essayons de rendre nos developpement compatibles avec les anciennes versions, ce qui vous permettra de changer de version de MySQL en quelques minutes! 4.3 Quelle version de MySQL utiliser.

Si vous être un client du support, n'envoyez pas le rapport en double sur l'adresse pour voir si quelqu'un expérimenté peut résoudre votre problème.

Pour savoir comment rapporter à propos de MyODBC, allez à 16.2 Comment rapporter des bugs avec MyODBC.

Pour des solutions aux problèmes courants, reportez vous à 18 Problèmes et erreurs fréquents.

Lorsque des informations vous sont envoyées individuellement, et pas à la liste de diffusion, il est de bon ton de rassembler toutes les réponses, et de les envoyer à la liste de diffusion pour que le bénéfices des réponses profite à tous.