8.1. How to report a bug — Mroonga vmrn_version documentation

Skip to main content
`Ctrl`+`K`

# 8.1. How to report a bug

There are some ways to report a bug.

You can use either way It makes no difference to us.

## 8.1.1. Submit a bug to the issue tracker

Mroonga project uses GitHub issue tracker.

You can use English or Japanese to report a bug.

## 8.1.2. Report a bug with the other ways

Mroonga project has Community for discussing about Mroonga. Please send an Email that describes a bug.

# 8.2. How to collect data for reporting a reproducible bug

There may be a case that Mroonga doesn’t work as expected. It may be a crash bug or SQL returns unexpected search results. To solve such a issues with you, We need a reproducible bug report.

For a reproducible bug report, it is better to report with the following information as much as you can because it is useful to investigate the reason which causes the bug.

Name | Description
--- | ---
Environment information | Installed packages information to detect what version is used. rpm:
    rpm -qa > INSTALLED.txt
deb:
    dpkg -l > INSTALLED.txt
On Windows, show us what zip package is used.
Executing query which triggers the issue | It shows what you did.
Sample schema and data | It is recommended to provide a minimum schema and sample data to reproduce the issue. It helps to solve the issue sooner.
MySQL error log | It may include backtrace information why crashed unexpectedly. It may exists on `/var/log/mysqld.log` for example. (It depends on `log-error` configuration)
groonga.log | It may include low level error information. It may exists on `/var/lib/mysql/groonga.log` for example. (It depends on `mroonga_log_file` configuration)

There is a case that it is not enough to reproduce a bug with above information. For such a case, additional information is required.

Name | Description
--- | ---
MySQL dump | It may be required to construct same database from scratch. It may be generated by `mysqldump -u USER -pPASSWORD --opt --flush-logs --single-transaction --master-data=2 --default-character-set=utf8 --hex-blob --databases DATABASE > dump.sql` and so on.
MySQL binlog | If dump data is enough to reproduce the issue, it is not required. It may exists on `/var/lib/mysql/mysql-bin.*` for example. (It depends on `log-bin` configuration)
MySQL data directory (Offline backup) | If dump data and binlog pair is lost, It may be required. It may exists on `/var/lib/mysql/` for example. (It depends on `datadir` configuration)