8.1. How to report a bug

There are two ways to report a bug:

  • Submit a bug to the issue tracker

  • Report a bug to the mailing list

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 to the mailing list

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)