Reporting bugs

Unfortunately, Manticore is not yet 100% bug free (even though we’re working hard towards that), so you might occasionally run into some issues.

Reporting as much as possible about each bug is very important - because to fix it, we need to be able either to reproduce and fix the bug, or to deduce what’s causing it from the information that you provide. So here are some instructions on how to do that.


Please issue the Github issue tracker Create a new ticket and describe your bug in details so both you and developers can save their time.


In case of crashes we sometimes can get enough info to fix from backtrace.

Manticore tries to write crash backtrace to its log file. It may look like this:


This is an example of a good backtrace - we can see mangled function names here.

But sometimes backtrace may look like this:


Developers can get nothing useful from those cryptic numbers. They’re ordinary humans and want to see function names. To help them you need to provide symbols (function and variable names). If you’ve installed sphinx by building from the sources, run the following command over your binary:

nm -n indexer > indexer.sym

Attach this file to bug report along with backtrace. You should however ensure that the binary is not stripped. Our official binary packages should be fine. (That, or we have the symbols stored.) However, if you manually build Manticore from the source tarball, do not run strip utility on that binary, and/or do not let your build/packaging system do that!

Core dumps

Sometimes the backtrace doesn’t provide enough information about the cause of a crash or the crash cannot be easily reproduced and core files are required for troubleshooting.

For the searchd daemon to record a core dump in case of a crash, the following needs to be ensured:

  • core dumping neds to be enabled on the running operating systems. Some operating systems do not have core dumping enabled by default.
  • searchd needs to be started with --coredump option.

Please note that searchd core files can use a lot of space as they include data from loaded indexes and each crash creates a new core file. Free space should be monitored while searchd runs with --coredump option enabled to avoid 100% disk usage.

Uploading your data

To fix your bug developers often need to reproduce it on their machines. To do this they need your sphinx.conf, index files, binlog (if present), sometimes data to index (like SQL tables or XMLpipe2 data files) and queries.

Attach your data to ticket. In case it’s too big to attach ask developers and they give you an address to write-only FTP created exactly for such puproses.