<<toc>>
This page contains general guidelines for reporting bugs in MariaDB.
== Is the bug already known?
First, check that the bug isn't already filed in the
[[http://bugs.launchpad.net/maria|MariaDB bugs database]]
or the [[http://bugs.mysql.com/|MySQL bugs database]] (if a bug is in
the MySQL bugs database, it doesn't need to be filed in the MariaDB bugs
database).
If you find the bug in either of the bug databases, please add a comment that
the bug also affects you along with any additional information you have that
may help us to find and fix the bug.
If the bug has not been reported elsewhere, then it's time to file a bug
report.
== Bug Report or Feature Request?
Feature requests are not the same as bug reports. Use [[Worklog]] to submit feature requests.
== How do I report a bug?
The easiest way to report simple bugs is to use the ##mysqlbug## script that
comes with your MariaDB installation. It's usually located in the ##bin/## or
##scripts/## directory. Just start the script, answer the questions and send
the bug. (It will be sent to the
[[https://launchpad.net/~maria-developers|maria-developers launchpad.net list]]).
For more complex bugs, here is the information we need to be able to fix it
quickly. The more information we get and the easier we can repeat the bug, the
faster it will be fixed.
A good bug report consists of:
#lower-alpha The environment (Operating system, hardware and MariaDB version) where the bug happened.
# Any related errors or warnings from the <<fixed>>hostname.err<</fixed>> file. This is normally in your database directory.
# Any background information you can provide ([[how-to-produce-a-full-stack-trace-for-mysqld-the-mariadb-server|stack trace]], tables)
# A test case or some other way to repeat the bug. This should preferably be in mysqltest format. See **mysqltest/README** for information about this.
# If it's impossible to do a test case, then providing us with a core dump + the corresponding binary would be of great help.
If the bug only affects MariaDB, you can file the bug to the [[http://bugs.launchpad.net/maria|MariaDB bugs database]].
If it also affects MySQL, then you should also file the bug to the [[http://bugs.mysql.com|MySQL bugs database]].
== Bugs status ==
The different statuses for bugs in [[https://bugs.launchpad.net/maria|launchpad]] are:
<<style class="darkheader-nospace-borders" style="font-size:0.8em">>
|= state |= Description
| Incomplete | We need more information of how to fix the bug |
| Invalid | Not a bug (Feature request?) |
| Won't Fix | A bug or feature that we don't plan to fix |
| In Progress | A developer is working actively to fix it |
| Fix Committed | Fix is committed to a main branch |
| Fix Released | Fix is committed to a main branch |
<</style>>
The normal process to fix a bug is as follows:
<<code>>
"In Progress" -> "Fix Released"
<</code>>
Developers who want to distinguish between committed to a main branch and
released in a binary, can use:
<<code>>
"In Progress" -> "Fix Committed" -> "Fix Released"
<</code>>
However in this case the developer needs to ensure that when a binary is released,
they update the state of their old committed bugs.
== How to build a MariaDB server that contains debug information ==
Here are instructions on how to build a mysqld that contains all the
information we need to fix the problem:
* Add the <<code>>--core<</code>> option to your ~/.my.cnf or /etc/my.cnf file under the [mysqld] tag.
* Get the latest [[contributing-code|MariaDB code from bzr]].
* Compile MariaDB with the **-g** compiler flag (Unix). The scripts in the **BUILD** directory will do this automatically for you.
* Shut down your old mysqld server
* Install the new compiled mysqld
* restart mysqld
Compiling with **-g** should not cause any notable slowdown of the server.
== Example of doing a debug build ==
Here is an example of how to do the compilation (assuming you are using AMD or Intel hardware)
<<code lang="sh" inline="false">>
cd mariadb-source-dir
./BUILD/compile-pentium-max
make
./client/mysqladmin shutdown
mv mariadb-install-dir/mysqld mariadb-install-dir/mysqld-old
cp sql/mysqld mariadb-install-dir/mysqld
'restart mysqld'
<</code>>
You can of course also do **make install**, but the above way allows
you to go back to your old binary if needed.
If you get any errors about wrong number of error messages, you can
fix that by copying the corresponding language file from **sql/share**
over your old ones (this should be reasonably safe to do).
<<code lang=sh inline=false>>
cp sql/share/english/* mariadb-install-dir/share/mysql/english
<</code>>
== What to do when you get a crash after installing a debug binary ==
Now when you get a crash do the following:
* Create a README file that described the problem. (You can use the mysqlbug script to generate a template for this).
* Create a tar file containing the core, the mysqld binary and README. If possible, also add any database files that could help us repeat the problem! <<code lang=sh inline=false>>
sh> tar cvfz /tmp/mariadb-bug-'short-description'.tgz mariadb-data-dir/core* mariadb-install-dir/libexec/mysqld README
<</code>>
* Send it to our secure server (the private directory is not accessibly by people outside of Monty Program Ab) <<code lang=sh inline=false>>
sh> ftp -a ftp.askmonty.org
ftp> cd private
ftp> binary
ftp> put /tmp/mariadb-bug-'short-description'.tgz
ftp> quit
<</code>>
* To be able to follow the progress, create a bug report in [[http://bugs.launchpad.net/maria|Launchpad]] about this. This should be easy to do based on the information you have in your README file.
If you require help with the above, want to ensure that the bug is fixed with high priority, or want someone to login to your server to find out what's wrong, you can always purchase a [[http://askmonty.org/wiki/Support|Support]] contract from Monty Program or use their consulting services.
