manticoresoftware/manticoresearch

Easy to use open source fast database for search | Good alternative to Elasticsearch now | Drop-in replacement for E in the ELK soon

Website • Downloads • Docs • Blog • Courses • Forum • Slack • Telegram (En) • Telegram (Ru) • Twitter • User feedback

 

Introduction

❗Read recent blog post about Manticore vs Elasticsearch❗

Manticore Search is an easy to use open source fast database for search. Good alternative for Elasticsearch. What distinguishes it from other solutions is:

• It's very fast and therefore more cost-efficient than alternatives, for example Manticore is:
  • 182x faster than MySQL for small data (reproducible❗)
  • 29x faster than Elasticsearch for log analytics (reproducible❗)
  • 15x faster than Elasticsearch for small dataset (reproducible❗)
  • 5x faster than Elasticsearch for medium-size data (reproducible❗)
  • 4x faster than Elasticsearch for big data (reproducible❗)
  • up to 2x faster max throughput than Elasticsearch's for data ingestion on a single server (reproducible❗)
• With its modern multithreading architecture and efficient query parallelization capabilities, Manticore is able to fully utilize all your CPU cores to achieve the quickest response times possible.
• The powerful and speedy full-text search works seamlessly with both small and large datasets.
• Row-wise storage for small, medium and big size datasets.
• For even larger datasets, Manticore offers columnar storage support through the Manticore Columnar Library, capable of handling datasets too big to fit in RAM.
• Performant secondary indexes are automatically created, saving you time and effort.
• The cost-based query optimizer optimizes search queries for optimal performance.
• Manticore is SQL-first, utilizing SQL as its native syntax, and offers compatibility with the MySQL protocol, allowing you to use your preferred MySQL client.
• With clients available in PHP, Python, JavaScript, Typescript, Java, Elixir, and Go, integration with Manticore Search becomes easy.
• Manticore also provides a programmatic HTTP JSON protocol for more versatile data and schema management.
• Built in C++, Manticore Search starts quickly and uses minimal RAM, with low-level optimizations contributing to its impressive performance.
• With real-time inserts, newly added documents are immediately accessible.
• Interactive courses are available through Interactive courses to make learning a breeze.
• Manticore also boasts built-in replication and load balancing for added reliability.
• Data can be synced from sources such as MySQL, PostgreSQL, ODBC, xml, and csv with ease.
• While not fully ACID-compliant, Manticore still supports transactions and binlog to ensure safe writes.
• Effortless data backup and recovery with built-in tools and SQL commands

Craigslist, Socialgist, PubChem, Rozetka and many others use Manticore for efficient searching and stream filtering.

Manticore Search was forked from Sphinx 2.3.2 in 2017.

More features

• Full-text search and relevance:
  • Over 20 full-text operators and over 20 ranking factors
  • Custom ranking
• Other search capabilities:
  • Rich filtering functionality
  • Faceted search
  • Geo-spatial search
  • Vector search
  • Spelling correction
  • Autocomplete
  • A wide range of functions for filtering and data manipulation
• Natural language processing (NLP):
  • Stemming
  • Lemmatization
  • Stopwords
  • Synonyms
  • Wordforms
  • Advanced tokenization at character and word level
  • Proper Chinese segmentation
  • Text highlighting
• Stream filtering using a "percolate" table
• High-availability:
  • Data can be distributed across servers and data-centers
  • Synchronous replication
  • Built-in load balancing
• Security:
  • https support
  • read-only mode
• Data safety:
  • manticore-backup tool and SQL command BACKUP to back up and restore your data
• Data storages:
  • row-wise - requires more RAM, provides faster performance
  • columnar - requires less RAM, still provides decent performance, but lower than the row-wise storage for some kinds of queries
  • docstore - doesn't require RAM at all, but allows only fetching original value, not sorting/grouping/filtering
• Performance optimizations:
  • Secondary indexes
  • Cost-based optimizer determines the most efficient execution plan of a search query
• Data types:
  • full-text field - inverted index
  • int, bigint and float numeric fields in row-wise and columnar fashion
  • multi-value attributes (array)
  • string and JSON
  • on-disk "stored" for key-value purpose
• Integrations:
  • Sync from MySQL and PostgreSQL
  • Sync from XML
  • Sync from CSV
  • With MySQL as a storage engine
  • With MySQL via FEDERATED engine
  • ProxySQL
  • Apache Superset
  • Grafana
  • Fluentbit
  • Logstash/Filebeat
  • Vector.dev
  • Mysqldump
  • Manticore Columnar Library

Installation

Docker

Docker image is available on Docker Hub.

To experiment with Manticore Search in Docker just run:

docker run -e EXTRA=1 --name manticore --rm -d manticoresearch/manticore && until docker logs manticore 2>&1 | grep -q "accepting connections"; do sleep 1; done && docker exec -it manticore mysql && docker stop manticore

You can then: create a table, add data and run searches. For example:

create table movies(title text, year int) morphology='stem_en' html_strip='1' stopwords='en';

insert into movies(title, year) values ('The Seven Samurai', 1954), ('Bonnie and Clyde', 1954), ('Reservoir Dogs', 1992), ('Airplane!', 1980), ('Raging Bull', 1980), ('Groundhog Day', 1993), ('<a href="http://google.com/">Jurassic Park</a>', 1993), ('Ferris Bueller\'s Day Off', 1986);

select highlight(), year from movies where match('the dog');

select highlight(), year from movies where match('days') facet year;

select * from movies where match('google');

Note that upon exiting the MySQL client, the Manticore container will be stopped and removed, resulting in no saved data, so use this way only for testing / sandboxing purposes.

Read the full instruction for the docker image for more details including our recommendations on running it in production.

Packages

Ubuntu, Debian, Centos, Windows and MacOS packages are here.

YUM repo for RHEL/Centos/Amazon/Oracle Linux

sudo yum install https://repo.manticoresearch.com/manticore-repo.noarch.rpm
sudo yum install manticore manticore-extra

APT repo for Ubuntu/Debian/Mint

wget https://repo.manticoresearch.com/manticore-repo.noarch.deb
sudo dpkg -i manticore-repo.noarch.deb
sudo apt update
sudo apt install manticore manticore-extra

Homebrew on MacOS

brew install manticoresoftware/tap/manticoresearch manticoresoftware/tap/manticore-extra

Windows

See instruction here.

Documentation and community sites

• Documentation
• Interactive courses
• Manticore Community Forum
• Public Slack chat
• Public Telegram chat (En)
• Public Telegram chat (Ru)
• Bug tracker

Third-party integrations

• https://dev.tiki.org/Manticore-Search - TikiWiki CMS Groupware integration
• https://github.com/EvilFreelancer/laravel-manticoresearch - Laravel ManticoreSearch plugin
• https://www.mediawiki.org/wiki/Extension:SphinxSearch - extension for MediaWiki
• https://github.com/gordonbanderson/silverstripe-manticore-search - integration for SilverStripe
• https://drwho.virtadpt.net/archive/2022-05-13/combining-manticore-and-searx/ - integration for SearX
• https://github.com/dimv36/sphinxlink - Extension for PostgreSQL for running search queries and returning data as PostgreSQL tables

How we can support you

Should your company require any help - we provide full-cycle services in the areas of Sphinx and Manticore Search:

• Audit
• Support
• Consulting
• Development
• Training

More details here

❤️ How you can support Manticore Search

Manticore Search is an Open Source project with development made possible by support from our core team, contributors, and sponsors. Building premium Open Source software is not easy. If you would like to make sure Manticore Search stays free, here is how you can help the project:

• Donation through PayPal
• Become our client and let us help you

License

Manticore Search is distributed under GPLv3 or later. Manticore Search uses and re-distributes other open-source components. Please check the component licenses directory for details.

manticoresearch's Issues

Incorrect longest commont subsequence calculation

Hello, I have following simple index:

sql_query = \
      SELECT 1 as id, "opel astra" as name \
      UNION SELECT 2 as id, "opel vectra astra" as name;

sql_field_string = name

When i execute query containing OR operator, I get wrong LCS factor value. It should be LCS=2 for first and second row, but I got value LCS=1. LCSS factor is affected as well:

mysql> select id, name, packedfactors() from test1 where match(' @name (opelu)|(opel)|(opela) (astru)|(astra)|(astry)') OPTION ranker=expr('1')\G;
*************************** 1. row ***************************
         id: 1
       name: opel astra
packedfactors(): bm25=452, bm25a=0.419112, field_mask=1, doc_word_count=2, field0=(lcs=1, hit_count=2, word_count=2, tf_idf=-0.105155, min_idf=-0.052577, max_idf=-0.052577, sum_idf=-0.105155, min_hit_pos=1, min_best_span_pos=1, exact_hit=0, max_window_hits=1, min_gaps=0, exact_order=0, lccs=1, wlccs=-0.052577, atc=0.005514), word0=(tf=0, idf=0.000000), word1=(tf=1, idf=-0.052577), word2=(tf=0, idf=0.000000), word3=(tf=0, idf=0.000000), word4=(tf=1, idf=-0.052577), word5=(tf=0, idf=0.000000)
*************************** 2. row ***************************
         id: 2
       name: opel vectra astra
packedfactors(): bm25=452, bm25a=0.419112, field_mask=1, doc_word_count=2, field0=(lcs=1, hit_count=2, word_count=2, tf_idf=-0.105155, min_idf=-0.052577, max_idf=-0.052577, sum_idf=-0.105155, min_hit_pos=1, min_best_span_pos=1, exact_hit=0, max_window_hits=1, min_gaps=1, exact_order=0, lccs=1, wlccs=-0.052577, atc=0.001642), word0=(tf=0, idf=0.000000), word1=(tf=1, idf=-0.052577), word2=(tf=0, idf=0.000000), word3=(tf=0, idf=0.000000), word4=(tf=1, idf=-0.052577), word5=(tf=0, idf=0.000000)
2 rows in set (0.01 sec)

When I slightly change word order in query to:

select id, name, packedfactors() from test1 where match(' @name (opela)|(opelu)|(opel) (astra)|(astru)|(astry)') OPTION ranker=expr('1')\G;

I got right lcs=2 value for first row, but wrong lcs=1 for second row. Incorrect LCS causes wrong sorting when using SPH04 ranker and operator OR.

fold_lemmas should respect hit count

mysql> call keywords('синей', 'myindex', 1 as stats);
+------+------------+--------------+------+------+
| qpos | tokenized | normalized | docs | hits |
+------+------------+--------------+------+------+
| 1 | синей | синь | 0 | 0 |
| 1 | синей | синий | 3732 | 7336 |
| 1 | синей | синеть | 0 | 0 |
| 1 | синей | =синей | 0 | 0 |
+------+------------+--------------+------+------+

As you can see, only "синий" has hits, and it should be chosen as "main" lemma, but when we try to fold,

mysql> call keywords('синей', 'myindex', 1 as fold_lemmas, 1 as stats);
+------+------------+--------------+------+------+
| qpos | tokenized | normalized | docs | hits |
+------+------------+--------------+------+------+
| 1 | синей | синеть | 3732 | 7336 |
+------+------------+--------------+------+------+

the chosen lemma is the last one

daemon crash on query

ldd searchd

    linux-vdso.so.1 => (0x00007ffd2b7b5000)
    libmysqlclient.so.18 => /usr/lib/libmysqlclient.so.18 (0x00007f9db0a09000)
    libpthread.so.0 => /lib/x86_64-linux-gnu/libpthread.so.0 (0x00007f9db07eb000)
    libz.so.1 => /lib/x86_64-linux-gnu/libz.so.1 (0x00007f9db05d1000)
    libdl.so.2 => /lib/x86_64-linux-gnu/libdl.so.2 (0x00007f9db03cd000)
    libpq.so.5 => /usr/lib/libpq.so.5 (0x00007f9db019e000)
    libodbc.so.1 => /usr/lib/x86_64-linux-gnu/libodbc.so.1 (0x00007f9daff36000)
    libexpat.so.1 => /lib/x86_64-linux-gnu/libexpat.so.1 (0x00007f9dafd0c000)
    libm.so.6 => /lib/x86_64-linux-gnu/libm.so.6 (0x00007f9dafa06000)
    librt.so.1 => /lib/x86_64-linux-gnu/librt.so.1 (0x00007f9daf7fd000)
    libstdc++.so.6 => /usr/lib/x86_64-linux-gnu/libstdc++.so.6 (0x00007f9daf4f9000)
    libgcc_s.so.1 => /lib/x86_64-linux-gnu/libgcc_s.so.1 (0x00007f9daf2e3000)
    libc.so.6 => /lib/x86_64-linux-gnu/libc.so.6 (0x00007f9daef1d000)
    libssl.so.1.0.0 => /lib/x86_64-linux-gnu/libssl.so.1.0.0 (0x00007f9daecbe000)
    libcrypto.so.1.0.0 => /lib/x86_64-linux-gnu/libcrypto.so.1.0.0 (0x00007f9dae8e2000)
    /lib64/ld-linux-x86-64.so.2 (0x00005602e8d3d000)
    libkrb5.so.3 => /usr/lib/x86_64-linux-gnu/libkrb5.so.3 (0x00007f9dae616000)
    libcom_err.so.2 => /lib/x86_64-linux-gnu/libcom_err.so.2 (0x00007f9dae412000)
    libgssapi_krb5.so.2 => /usr/lib/x86_64-linux-gnu/libgssapi_krb5.so.2 (0x00007f9dae1cb000)
    libldap_r-2.4.so.2 => /usr/lib/x86_64-linux-gnu/libldap_r-2.4.so.2 (0x00007f9dadf79000)
    libltdl.so.7 => /usr/lib/x86_64-linux-gnu/libltdl.so.7 (0x00007f9dadd6f000)
    libk5crypto.so.3 => /usr/lib/x86_64-linux-gnu/libk5crypto.so.3 (0x00007f9dadb3f000)
    libkrb5support.so.0 => /usr/lib/x86_64-linux-gnu/libkrb5support.so.0 (0x00007f9dad934000)
    libkeyutils.so.1 => /lib/x86_64-linux-gnu/libkeyutils.so.1 (0x00007f9dad730000)
    libresolv.so.2 => /lib/x86_64-linux-gnu/libresolv.so.2 (0x00007f9dad514000)
    liblber-2.4.so.2 => /usr/lib/x86_64-linux-gnu/liblber-2.4.so.2 (0x00007f9dad305000)
    libsasl2.so.2 => /usr/lib/x86_64-linux-gnu/libsasl2.so.2 (0x00007f9dad0ea000)
    libgssapi.so.3 => /usr/lib/x86_64-linux-gnu/libgssapi.so.3 (0x00007f9daceab000)
    libgnutls.so.26 => /usr/lib/x86_64-linux-gnu/libgnutls.so.26 (0x00007f9dacbed000)
    libgcrypt.so.11 => /lib/x86_64-linux-gnu/libgcrypt.so.11 (0x00007f9dac96d000)
    libheimntlm.so.0 => /usr/lib/x86_64-linux-gnu/libheimntlm.so.0 (0x00007f9dac763000)
    libkrb5.so.26 => /usr/lib/x86_64-linux-gnu/libkrb5.so.26 (0x00007f9dac4db000)
    libasn1.so.8 => /usr/lib/x86_64-linux-gnu/libasn1.so.8 (0x00007f9dac23a000)
    libhcrypto.so.4 => /usr/lib/x86_64-linux-gnu/libhcrypto.so.4 (0x00007f9dac006000)
    libroken.so.18 => /usr/lib/x86_64-linux-gnu/libroken.so.18 (0x00007f9dabdf1000)
    libtasn1.so.6 => /usr/lib/x86_64-linux-gnu/libtasn1.so.6 (0x00007f9dabbdd000)
    libp11-kit.so.0 => /usr/lib/x86_64-linux-gnu/libp11-kit.so.0 (0x00007f9dab99a000)
    libgpg-error.so.0 => /lib/x86_64-linux-gnu/libgpg-error.so.0 (0x00007f9dab795000)
    libwind.so.0 => /usr/lib/x86_64-linux-gnu/libwind.so.0 (0x00007f9dab56c000)
    libheimbase.so.1 => /usr/lib/x86_64-linux-gnu/libheimbase.so.1 (0x00007f9dab35d000)
    libhx509.so.5 => /usr/lib/x86_64-linux-gnu/libhx509.so.5 (0x00007f9dab114000)
    libsqlite3.so.0 => /usr/lib/x86_64-linux-gnu/libsqlite3.so.0 (0x00007f9daae5b000)
    libcrypt.so.1 => /lib/x86_64-linux-gnu/libcrypt.so.1 (0x00007f9daac21000)
    libffi.so.6 => /usr/lib/x86_64-linux-gnu/libffi.so.6 (0x00007f9daaa19000)

Daemon won't stop when using thread_pool workers

I'm finding that I can't stop a daemon normally (using searchd --config sphinx.conf --stopwait) if workers is set to thread_pool (or not set at all, thus using that as the default value). Using workers = threads is fine.

A quick example configuration:

searchd
{
  listen        = 9306:mysql41
  log           = searchd.log
  query_log     = searchd.query.log
  # workers       = threads
  pid_file      = searchd.pid
  binlog_path   = .
}

index products
{
  type = rt
  path = products
  docinfo = extern
  rt_field = name
  rt_attr_uint = price
}

# boots fine:
searchd --config sphinx.conf
# but this hangs:
searchd --config sphinx.conf --stopwait
# so, control-c, then:
kill -9 `cat searchd.pid`
# then uncomment the workers setting, and stopping then works straight away.

The daemon log does note the SIGTERM request, but both processes don't actually stop.

I found this issue when testing the Sphinx-related Ruby libraries I maintain (Riddle, Thinking Sphinx) using the latest manticore (2.6.1 fefa1c34@180104 dev, compiled from master, on macOS Sierra, with both MySQL and PostgreSQL support enabled). If there's any additional information that would help, do let me know.

Some bugs

Good news. My readers asked me to compare the projects 'Manticore' and 'Sphinx' in terms of code quality. I can do it only with my proven method by testing projects using PVS-Studio static analyzer and figure out the error density in code. Therefore, I checked the C and C++ code in these projects and, in my opinion, the quality of code in Manticore is higher than the quality of Sphinx code. Surely, this is a very narrow view and I do not claim to be authentic in my research. However, I was asked to do this work, and I did a comparison as I could.

Nevertheless, there are errors that mast be fix. Details in the article: "Code of the Manticore project is better than code of the Sphinx project".

Request for community: please, test out new feature JSON queries and give us your feedback

New Manticore Search 2.5.1 Release presents JSON queries via HTTP. Now you might query your data via curl or directly web application. It is intersting to know new JSON interface is similar to Elastic ;)

While it doesn’t have yet all the functionality of SphinxQL, it allows performing searching and data manipulation operations (insert/update/replace/deletes).

Official documentation on our site: http://docs.manticoresearch.com/latest/html

You can also read about JSON quieries in our gitlab repository:
http://manticoresearch.gitlab.io/dev/httpapi_reference.html#json-api

All the info about separate operations you can find here:
http://manticoresearch.gitlab.io/dev/http_reference/json_search.html
http://manticoresearch.gitlab.io/dev/http_reference/json_update.html
http://manticoresearch.gitlab.io/dev/http_reference/json_delete.html

How to make several operations at once check here:
http://manticoresearch.gitlab.io/dev/http_reference/json_bulk.html

We need you help to test how JSON queries work on your data and give us your feedback.

Please, let us know if you have any questions/concerns about JSON queries. Thank you!

Can someone point me out where the data is stored?

Can someone point me out where the data is stored and how it's stored? Which lines etc. I would like to write the backend storage to be based on leveldb etc

Can this be done? If i know how the mechanism works, i can contribute too. Please revert. Thanks.

Crash of searchd v2.2.11

Hello!

Recently we have a few crashes with following post mortem log:

------- FATAL: CRASH DUMP -------
[Wed Nov 1 05:07:31.691 2017] [ 6979]

--- crashed SphinxAPI request dump ---
AAABGQAAAdcAAAAAAAAAAQAAAAAAABOIAAAABgAAAAIAAAAAAAAAAAAAACNAY29tcGFueV9pZF9pZHggY29tcGFu
eV9pZF8xMDg5NzQwNgAAAAAAAAAHcHJvZHVjdAAAAAEAAAAAAAAAAAAAAAAAAAAAAAAABQAAAA5zcGhp
bnhfZGVsZXRlZAAAAAAAAAABAAAAAAAAAAAAAAAAAAAACWNsYXNzX2NyYwAAAAAAAAABAAAAALydhNYA
AAAAAAAACmNvbXBhbnlfaWQAAAAAAAAAAQAAAAAApkf+AAAAAAAAAAVzdGF0ZQAAAAAAAAAEAAAAAAAA
AAEAAAAAAAAAAgAAAAAAAAADAAAAAAAAAAUAAAAAAAAADHB1YmxpY19zdGF0ZQAAAAAAAAABAAAA
AAAAAAEAAAAAAAAABAAAAA5wcm9kdWN0X2dyb3VwcwAAE4gAAAAMQHdlaWdodCBERVNDAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAQAAAAEbmFtZQAAIygAAAAIYW5ub3VuY2UAAAAeAAAACHN5bm9u
eW1zAAAAAQAAAAthcnRpY2xlX2lkeAAAAAEAAAAAAAAAAAAAABJzcGhpbnhfaW50ZXJuYWxfaWQ=
--- request dump end ---
Sphinx 2.2.11-id64-release (95ae9a6)
Handling signal 11
-------------- backtrace begins here ---------------
Program compiled with x86_64-pc-linux-gnu-gcc 4.9.4
Configured with flags: '--prefix=/usr' '--host=x86_64-pc-linux-gnu' '--mandir=/usr/share/man' '--infodir=/usr/share/info' '--datadir=/usr/share' '--sysconfdir=/etc' '--localstatedir=/var/lib' '--disable-dependency-tracking' '--libdir=/usr/lib64' '--sysconfdir=/etc/sphinx' '--
enable-id64' '--without-debug' '--with-mysql' '--without-unixodbc' '--with-pgsql' '--without-libstemmer' '--with-syslog' '--without-libexpat' '--build=x86_64-pc-linux-gnu' 'build_alias=x86_64-pc-linux-gnu' 'host_alias=x86_64-pc-linux-gnu' 'CFLAGS=-O2 -march=nocona -pipe' 'LDFL
AGS=-Wl,-O1 -Wl,--as-needed' 'CXXFLAGS=-O2 -march=nocona -pipe'
Host OS is Linux oberon 4.4.52-gentoo-universal-03 0000013 SMP Mon Apr 3 09:58:58 +05 2017 x86_64 Intel(R) Xeon(R) CPU E5-2690 v2 @ 3.00GHz GenuineIntel GNU/Linux
Stack bottom = 0x7f4a24744ef7, thread stack size = 0x100000
[Wed Nov 1 05:07:32.000 2017] [34789] FATAL: Cannot get stack frame pointer on this architecture
Trying system backtrace:
begin of system symbols:
searchd[0x5605d6]
searchd[0x40d352]
/lib64/libpthread.so.0(+0x10460)[0x7f4a94430460]
searchd[0x667dc5]
searchd[0x64b269]
searchd[0x445fbf]
searchd[0x44e941]
searchd[0x450180]
searchd[0x4504a3]
searchd[0x455e13]
searchd[0x456028]
searchd[0x407733]
searchd[0x5684df]
/lib64/libpthread.so.0(+0x728c)[0x7f4a9442728c]
/lib64/libc.so.6(clone+0x6d)[0x7f4a930bd57d]
-------------- backtrace ends here ---------------
Please, create a bug report in our bug tracker (http://sphinxsearch.com/bugs [^]) and attach there:
a) searchd log, b) searchd binary, c) searchd symbols.
Look into the chapter 'Reporting bugs' in the documentation
(/usr/share/doc/sphinx/sphinx.txt or http://sphinxsearch.com/docs/current.html#reporting-bugs [^])
--- BT to source lines (depth 15): ---
--- BT to source lines finished ---
--- 131 active threads ---

Attached searchd symobls here:
searchd.tar.gz

My little experiment with gdb show me that the issue is manifested in the addition of numbers in macros:
https://gist.github.com/isqad/92450e3d2cc05af2258f082c1d078c26

Connecting through mysql protocol on mac

I'm developing a web app locally on my Mac (OS X 10.13.1). I upgraded my old Sphinx Search 2.2.11 to latest Manticore provided by our website.

I'm connecting to Manticore through the mysql protocol. In my sphinx.conf this is configured like this:

searchd
{
    listen = 127.0.0.1:9306:mysql41
    [...]
}

When I try to connect to sphinx through MySQL searchd creates a crash dump:

------- FATAL: CRASH DUMP -------
[Tue Dec  5 13:08:34.357 2017] [42405]

--- crashed invalid query ---

--- request dump end ---
Sphinx 2.5.1 b751d2b7@171123 id64-release
Handling signal 11
-------------- backtrace begins here ---------------
Program compiled with 4.2.1
Configured with flags: Configured by CMake with these definitions: -DCMAKE_BUILD_TYPE=RelWithDebInfo -DDISTR_BUILD=macos -DDL_EXPAT=1 -DEXPAT_LIB=libexpat.dylib -DUSE_LIBICONV=1 -DDL_MYSQL=1 -DMYSQL_LIB=libmysqlclient.dylib -DDL_PGSQL=1 -DPGSQL_LIB=libpq.dylib -DDATADIR=/var/data -DSPLIT_SYMBOLS=ON -DUSE_BISON=ON -DUSE_FLEX=ON -DUSE_SYSLOG=1 -DWITH_EXPAT=ON -DWITH_ICONV=ON -DWITH_MYSQL=ON -DWITH_PGSQL=ON -DWITH_RE2=ON -DWITH_STEMMER=ON -DWITH_ZLIB=ON
Host OS is Darwin Air-Aleksej.klirik.pw 17.2.0 Darwin Kernel Version 17.2.0: Fri Sep 29 18:27:05 PDT 2017
Stack bottom = 0x700004900edf, thread stack size = 0x100000
Trying manual backtrace:
Something wrong with thread stack, manual backtrace may be incorrect (fp=0x700004900750)
Stack looks OK, attempting backtrace.
0x10fbfdde3
0x700004900df0
0x6b636f73206e6f20
0x10fc7a2f5
0x10fc6e904
0x10fdc89b4
0x7fff73fda6c1
0x7fff73fda56d
0x7fff73fd9c5d
0x0
Something wrong in frame pointers, manual backtrace failed (fp=0)
Trying system backtrace:
begin of manual symbols:
10fdc538b
10fbfdde3
7fff73fd0f5a
6b636f73206e6f20
10fc7a2f5
10fc6e904
10fdc89b4
7fff73fda6c1
7fff73fda56d
7fff73fd9c5d
-------------- backtrace ends here ---------------
Please, create a bug report in our bug tracker (https://github.com/manticoresoftware/manticore/issues)
and attach there:
a) searchd log, b) searchd binary, c) searchd symbols.
Look into the chapter 'Reporting bugs' in the documentation
(http://docs.manticoresearch.com/latest/html/reporting_bugs.html)
--- BT to source lines (depth 10): ---
conversion failed (error 'No such file or directory'):
  1. Run the command provided below over the crashed binary (for example, './searchd'):
  2. Attach the source.txt to the bug report.
addr2line -e ./searchd 0xfdc538b 0xfbfdde3 0x73fd0f5a 0x206e6f20 0xfc7a2f5 0xfc6e904 0xfdc89b4 
0x73fda6c1 0x73fda56d 0x73fd9c5d > source.txt
--- BT to source lines finished ---
--- 1 active threads ---
thd 0, proto sphinxql, state handshake, command SYSTEM
------- CRASH DUMP END -------

The mysql command line client returns this:

ERROR 2013 (HY000): Lost connection to MySQL server at 'reading initial communication packet', system error: 54

Whats wrong here? :/

SUGGEST/QSUGGEST for distributed index

From https://forum.manticoresearch.com/t/add-distributed-index-support-for-suggest-qsuggest/80

Currently SUGGEST/QSUGGEST only operates on a single index, it probably should work like CALL KEYWORDS which has distributed index support.

Request for community: please, give us feedback about Percolate Queries

Manticore 2.6.0 introduces new feature known as percolate queries, prospective search or search in reverse. As opposed to normal workflow where documents are stored in an index and queries are run against it, this technique allows persistent storing queries and test if documents match against them. The queries are stored in a new index type – percolate – similar to a RealTime index and a new command CALL PQ can be used to test if a document or batch of documents match the stored queries.

Official documentation on our site: http://docs.manticoresearch.com/latest/html

For more info about PQ, please, check here https://manticoresearch.com/2017/12/29/percolate-queries/

We need you help to test Percolate Quieries feature and give us your feedback.

Please, let us know if you have any questions/concerns about Percolate queries. Thank you!

agent_retry_count does not work with ha_strategy nodeads and noerrors

The recent changes in the code (sphinxsearch/sphinx@66ea9fc [^]) to retry a failed query do the job partially, as from our tests, only work with roundrobin ha_strategy. This has a major drawback, as the dead nodes dictate a delay on every query equal with agent_query_timeout + agent_retry_delay depending if this hosts is timing out or responding with connection refused. Also, the retry count setting has a hardcoded value of 10, not sure if this matters at all:

[1064] index products: agent 10.211.69.100:9312: remote error: retry count out of bounds (count=10)

The bottom line is, nodeads and noerror strategies needs to respect the retry count setting and retry another agent without failing any requests, while also keeping the low response time (by not trying dead nodes). For the test we compiled sphinx from the master branch, so version 2.3.2-id64-dev.

OPTIMIZE INDEX breaks changes from ALTER RTINDEX rt RECONFIGURE

Use RECONFIGURE to add 'min_infix_len = 3'. SELECT reports query word mismatch (as expected).

REPLACE into the index all documents. SELECT still reports query word mismatch (it would be nice if it did not, since all old data has been replaced), but now 'wordfragment*' matches some results.

FLUSH RAMCHUNK. SELECT still has mismatch, 'wordfragment*' still matches.

Problem:
OPTIMIZE INDEX. SELECT still has mismatch (no surprise there). However, 'wordfragment*' now has zero matches.

Truncating, then rebuilding the index does avoid both the annoying mismatch, and keeps 'wordfragment*' working, but this is not a good solution since it brings down the search index for a period of time while it is being rebuilt.

Ubuntu 14.04, 64-bit

Selective expand_keywords (exact form, not infix/prefix expansion)

The new morphology_skip_fields works great. But to avoid having to modify queries manually, its useful to use expand_keywords to automatically add the exact form operator (=word).

... have just run into a problem on one my production indexes, also have min_prefix_len enabled to (with effective enable_star=1), so can do prefix matches if want, however turning on expand_keywords is transparently enabling part word matches, because word expands to (word | word* | =word)

So this is a request to be able to use enable_keywords, but ONLY get exact form expansion, not wildcard expansion.

ie so word just expands to (word | =word) - even tho min_infix_len/min_prefix_len is used

Not sure on syntax, but expand_keywords = 2 would be the easy way. But expand_keywords = exact would be more semantic. Then could also do expand_keywords = star or even star,exact.
With 1 remaining as an alias for star,exact

Documents without a key returned when using numeric operators on a JSON attribute

The documentation says:
"When you filter on a key of a JSON attribute, documents that don't include the key will simply be ignored."

In Sphinx version 2.2.10-release the described behaviour works well with numeric operators, but in version 2.2.11-release (and 2.3.2-beta) results also include documents that don't have a specified key.

Example:

INSERT INTO rt (id, json_data) VALUES (1, '{ }');
INSERT INTO rt (id, json_data) VALUES (2, '{ price: 20 }');
INSERT INTO rt (id, json_data) VALUES (3, '{ price: 30 }');
INSERT INTO rt (id, json_data) VALUES (4, '{ }');

Results returned by Sphinx version 2.2.10-release

SELECT * FROM rt WHERE json_data.price < 25;
+------+--------------+
| id | json_data |
+------+--------------+
| 2 | {"price":20} |
+------+--------------+
1 row in set (0.03 sec)

Results returned by Sphinx version 2.2.11-release

SELECT * FROM rt WHERE json_data.price < 25;
+------+--------------+
| id | json_data |
+------+--------------+
| 1 | {} |
| 2 | {"price":20} |
| 4 | {} |
+------+--------------+
3 rows in set (0.00 sec)

A workaround is to change the query and exclude those documents with NULL values

SELECT * FROM rt WHERE json_data.price < 25 AND json_data.price IS NOT NULL;

CONFIG:

index rt {
    type = rt
    path = /var/lib/sphinx
    rt_field = title
    rt_attr_json = json_data
}

searchd {
    listen = localhost:9306:mysql41
    query_log_format = sphinxql
    log = searchd1.log
    query_log = query1.log
    pid_file = searchd1.pid
    workers = threads
    persistent_connections_limit = 1000
    binlog_path =
}

`blend_chars` does not work if exceptions are used

If I use an exceptions file with anything in it, blend_chars seems to have no effect.

sphinx.conf

source manticore_test {
  sql_query = SELECT 1, 'red-black' UNION SELECT 2, 'red+black'
}

index manticore_test  {
  blend_chars = +, -, !, /
  exceptions = exceptions.txt
  source    = manticore_test
}

with exceptions.txt

exceptions.txt contains Sample Exception => SampleException

mysql> select * from manticore_test where match('red+black');
Empty set (0.00 sec)

mysql> select * from manticore_test where match('red-black');
Empty set (0.00 sec)

without exceptions.txt

exceptions.txt exists but is empty

mysql> select * from manticore_test where match('red-black')\G
*************************** 1. row ***************************
id: 1
1 row in set (0.00 sec)

mysql> select * from manticore_test where match('red+black')\G
*************************** 1. row ***************************
id: 2
1 row in set (0.00 sec)

texts containing ligatures

Contents contain lots of ligatures (such as œ = oe, æ = ae).

I want users not to care about this, so they should be able to type cœur or coeur and get the same results, typeset as they are in the original text.

Currently what I'm doing (under sphinx 2.2.5-id64-dev (r4824)) is crazy: I extract all the words containing these ligatures from the index.dict, and convert them to a flat file and use wordforms = …

Is there a way to do this in a cleaner fashion?

Dockerfile

Do you plan to provide a docker image ?

FATAL: CRASH DUMP after running 1 hour

manticore_2.6.0-171228-b84f229-release-stemmer.wheezy_amd64-bin.deb
Debian GNU/Linux 7.11 (wheezy)

Delta index will update when user change product data
Crash on 10:37:40

[Wed Jan 17 09:37:52.489 2018] [6972] watchdog: main process 6973 forked ok
[Wed Jan 17 09:37:52.496 2018] [6973] listening on all interfaces, port=9313
[Wed Jan 17 09:37:52.523 2018] [6973] listening on all interfaces, port=9307
[Wed Jan 17 09:37:52.573 2018] [6973] binlog: replaying log /var/www/vhosts/elf925.com/sphinx/log/binlog.001
[Wed Jan 17 09:37:52.576 2018] [6973] binlog: replay stats: 0 rows in 0 commits; 0 updates, 0 reconfigure; 0 indexes
[Wed Jan 17 09:37:52.576 2018] [6973] binlog: finished replaying /var/www/vhosts/elf925.com/sphinx/log/binlog.001; 0.0 MB in 0.000 sec
[Wed Jan 17 09:37:52.576 2018] [6973] binlog: replaying log /var/www/vhosts/elf925.com/sphinx/log/binlog.002
[Wed Jan 17 09:37:52.584 2018] [6973] binlog: replay stats: 0 rows in 0 commits; 0 updates, 0 reconfigure; 0 indexes
[Wed Jan 17 09:37:52.584 2018] [6973] binlog: finished replaying /var/www/vhosts/elf925.com/sphinx/log/binlog.002; 0.0 MB in 0.000 sec
[Wed Jan 17 09:37:52.584 2018] [6973] binlog: replaying log /var/www/vhosts/elf925.com/sphinx/log/binlog.003
[Wed Jan 17 09:37:52.585 2018] [6973] binlog: replay stats: 0 rows in 0 commits; 0 updates, 0 reconfigure; 0 indexes
[Wed Jan 17 09:37:52.585 2018] [6973] binlog: finished replaying /var/www/vhosts/elf925.com/sphinx/log/binlog.003; 0.0 MB in 0.000 sec
[Wed Jan 17 09:37:52.585 2018] [6973] binlog: replaying log /var/www/vhosts/elf925.com/sphinx/log/binlog.003
[Wed Jan 17 09:37:52.585 2018] [6973] binlog: replay stats: 0 rows in 0 commits; 0 updates, 0 reconfigure; 0 indexes
[Wed Jan 17 09:37:52.585 2018] [6973] binlog: finished replaying /var/www/vhosts/elf925.com/sphinx/log/binlog.003; 0.0 MB in 0.000 sec
[Wed Jan 17 09:37:52.585 2018] [6973] binlog: replaying log /var/www/vhosts/elf925.com/sphinx/log/binlog.003
[Wed Jan 17 09:37:52.585 2018] [6973] binlog: replay stats: 0 rows in 0 commits; 0 updates, 0 reconfigure; 0 indexes
[Wed Jan 17 09:37:52.585 2018] [6973] binlog: finished replaying /var/www/vhosts/elf925.com/sphinx/log/binlog.003; 0.0 MB in 0.000 sec
[Wed Jan 17 09:37:52.585 2018] [6973] binlog: replaying log /var/www/vhosts/elf925.com/sphinx/log/binlog.004
[Wed Jan 17 09:37:52.600 2018] [6973] binlog: replay stats: 0 rows in 0 commits; 0 updates, 0 reconfigure; 0 indexes
[Wed Jan 17 09:37:52.600 2018] [6973] binlog: finished replaying /var/www/vhosts/elf925.com/sphinx/log/binlog.004; 0.0 MB in 0.000 sec
[Wed Jan 17 09:37:52.600 2018] [6973] binlog: replaying log /var/www/vhosts/elf925.com/sphinx/log/binlog.005
[Wed Jan 17 09:37:52.601 2018] [6973] binlog: replay stats: 0 rows in 0 commits; 0 updates, 0 reconfigure; 0 indexes
[Wed Jan 17 09:37:52.601 2018] [6973] binlog: finished replaying /var/www/vhosts/elf925.com/sphinx/log/binlog.005; 0.0 MB in 0.000 sec
[Wed Jan 17 09:37:52.601 2018] [6973] binlog: replaying log /var/www/vhosts/elf925.com/sphinx/log/binlog.006
[Wed Jan 17 09:37:52.620 2018] [6973] binlog: replay stats: 0 rows in 0 commits; 0 updates, 0 reconfigure; 0 indexes
[Wed Jan 17 09:37:52.620 2018] [6973] binlog: finished replaying /var/www/vhosts/elf925.com/sphinx/log/binlog.006; 0.0 MB in 0.000 sec
[Wed Jan 17 09:37:52.620 2018] [6973] binlog: replaying log /var/www/vhosts/elf925.com/sphinx/log/binlog.007
[Wed Jan 17 09:37:52.628 2018] [6973] binlog: replay stats: 0 rows in 0 commits; 0 updates, 0 reconfigure; 0 indexes
[Wed Jan 17 09:37:52.628 2018] [6973] binlog: finished replaying /var/www/vhosts/elf925.com/sphinx/log/binlog.007; 0.0 MB in 0.000 sec
[Wed Jan 17 09:37:52.628 2018] [6973] binlog: replaying log /var/www/vhosts/elf925.com/sphinx/log/binlog.008
[Wed Jan 17 09:37:52.628 2018] [6973] binlog: replay stats: 0 rows in 0 commits; 0 updates, 0 reconfigure; 0 indexes
[Wed Jan 17 09:37:52.628 2018] [6973] binlog: finished replaying /var/www/vhosts/elf925.com/sphinx/log/binlog.008; 0.0 MB in 0.000 sec
[Wed Jan 17 09:37:52.628 2018] [6973] binlog: replaying log /var/www/vhosts/elf925.com/sphinx/log/binlog.009
[Wed Jan 17 09:37:52.632 2018] [6973] binlog: replay stats: 0 rows in 0 commits; 0 updates, 0 reconfigure; 0 indexes
[Wed Jan 17 09:37:52.632 2018] [6973] binlog: finished replaying /var/www/vhosts/elf925.com/sphinx/log/binlog.009; 0.0 MB in 0.000 sec
[Wed Jan 17 09:37:52.632 2018] [6973] binlog: replaying log /var/www/vhosts/elf925.com/sphinx/log/binlog.010
[Wed Jan 17 09:37:52.632 2018] [6973] binlog: replay stats: 0 rows in 0 commits; 0 updates, 0 reconfigure; 0 indexes
[Wed Jan 17 09:37:52.632 2018] [6973] binlog: finished replaying /var/www/vhosts/elf925.com/sphinx/log/binlog.010; 0.0 MB in 0.000 sec
[Wed Jan 17 09:37:52.632 2018] [6973] binlog: replaying log /var/www/vhosts/elf925.com/sphinx/log/binlog.011
[Wed Jan 17 09:37:52.633 2018] [6973] binlog: replay stats: 0 rows in 0 commits; 0 updates, 0 reconfigure; 0 indexes
[Wed Jan 17 09:37:52.633 2018] [6973] binlog: finished replaying /var/www/vhosts/elf925.com/sphinx/log/binlog.011; 0.0 MB in 0.000 sec
[Wed Jan 17 09:37:52.633 2018] [6973] binlog: replaying log /var/www/vhosts/elf925.com/sphinx/log/binlog.012
[Wed Jan 17 09:37:52.646 2018] [6973] binlog: replay stats: 0 rows in 0 commits; 0 updates, 0 reconfigure; 0 indexes
[Wed Jan 17 09:37:52.646 2018] [6973] binlog: finished replaying /var/www/vhosts/elf925.com/sphinx/log/binlog.012; 0.0 MB in 0.000 sec
[Wed Jan 17 09:37:52.646 2018] [6973] binlog: replaying log /var/www/vhosts/elf925.com/sphinx/log/binlog.012
[Wed Jan 17 09:37:52.646 2018] [6973] binlog: replay stats: 0 rows in 0 commits; 0 updates, 0 reconfigure; 0 indexes
[Wed Jan 17 09:37:52.646 2018] [6973] binlog: finished replaying /var/www/vhosts/elf925.com/sphinx/log/binlog.012; 0.0 MB in 0.000 sec
[Wed Jan 17 09:37:52.646 2018] [6973] binlog: replaying log /var/www/vhosts/elf925.com/sphinx/log/binlog.012
[Wed Jan 17 09:37:52.647 2018] [6973] binlog: replay stats: 0 rows in 0 commits; 0 updates, 0 reconfigure; 0 indexes
[Wed Jan 17 09:37:52.647 2018] [6973] binlog: finished replaying /var/www/vhosts/elf925.com/sphinx/log/binlog.012; 0.0 MB in 0.000 sec
[Wed Jan 17 09:37:52.647 2018] [6973] binlog: replaying log /var/www/vhosts/elf925.com/sphinx/log/binlog.013
[Wed Jan 17 09:37:52.659 2018] [6973] binlog: replay stats: 0 rows in 0 commits; 0 updates, 0 reconfigure; 0 indexes
[Wed Jan 17 09:37:52.659 2018] [6973] binlog: finished replaying /var/www/vhosts/elf925.com/sphinx/log/binlog.013; 0.0 MB in 0.000 sec
[Wed Jan 17 09:37:52.659 2018] [6973] binlog: replaying log /var/www/vhosts/elf925.com/sphinx/log/binlog.014
[Wed Jan 17 09:37:52.660 2018] [6973] binlog: replay stats: 0 rows in 0 commits; 0 updates, 0 reconfigure; 0 indexes
[Wed Jan 17 09:37:52.660 2018] [6973] binlog: finished replaying /var/www/vhosts/elf925.com/sphinx/log/binlog.014; 0.0 MB in 0.000 sec
[Wed Jan 17 09:37:52.660 2018] [6973] binlog: finished replaying total 18 in 0.087 sec
[Wed Jan 17 09:37:52.687 2018] [6973] accepting connections
[Wed Jan 17 09:37:52.687 2018] [7012] prereading 4 indexes
[Wed Jan 17 09:37:52.746 2018] [7012] prereaded 4 indexes in 0.059 sec
[Wed Jan 17 09:38:23.298 2018] [6973] caught SIGTERM, shutting down
[Wed Jan 17 09:38:23.408 2018] [6973] shutdown complete
[Wed Jan 17 09:38:23.410 2018] [6972] watchdog: main process 6973 exited cleanly (exit code 0), shutting down
[Wed Jan 17 09:38:39.481 2018] [7074] watchdog: main process 7075 forked ok
[Wed Jan 17 09:38:39.481 2018] [7075] listening on all interfaces, port=9313
[Wed Jan 17 09:38:39.481 2018] [7075] listening on all interfaces, port=9307
[Wed Jan 17 09:38:39.489 2018] [7075] binlog: replaying log /var/www/vhosts/elf925.com/sphinx/log/binlog.001
[Wed Jan 17 09:38:39.489 2018] [7075] binlog: replay stats: 0 rows in 0 commits; 0 updates, 0 reconfigure; 0 indexes
[Wed Jan 17 09:38:39.489 2018] [7075] binlog: finished replaying /var/www/vhosts/elf925.com/sphinx/log/binlog.001; 0.0 MB in 0.000 sec
[Wed Jan 17 09:38:39.489 2018] [7075] binlog: replaying log /var/www/vhosts/elf925.com/sphinx/log/binlog.002
[Wed Jan 17 09:38:39.489 2018] [7075] binlog: replay stats: 0 rows in 0 commits; 0 updates, 0 reconfigure; 0 indexes
[Wed Jan 17 09:38:39.489 2018] [7075] binlog: finished replaying /var/www/vhosts/elf925.com/sphinx/log/binlog.002; 0.0 MB in 0.000 sec
[Wed Jan 17 09:38:39.489 2018] [7075] binlog: replaying log /var/www/vhosts/elf925.com/sphinx/log/binlog.003
[Wed Jan 17 09:38:39.489 2018] [7075] binlog: replay stats: 0 rows in 0 commits; 0 updates, 0 reconfigure; 0 indexes
[Wed Jan 17 09:38:39.489 2018] [7075] binlog: finished replaying /var/www/vhosts/elf925.com/sphinx/log/binlog.003; 0.0 MB in 0.000 sec
[Wed Jan 17 09:38:39.489 2018] [7075] binlog: replaying log /var/www/vhosts/elf925.com/sphinx/log/binlog.003
[Wed Jan 17 09:38:39.489 2018] [7075] binlog: replay stats: 0 rows in 0 commits; 0 updates, 0 reconfigure; 0 indexes
[Wed Jan 17 09:38:39.489 2018] [7075] binlog: finished replaying /var/www/vhosts/elf925.com/sphinx/log/binlog.003; 0.0 MB in 0.000 sec
[Wed Jan 17 09:38:39.489 2018] [7075] binlog: replaying log /var/www/vhosts/elf925.com/sphinx/log/binlog.003
[Wed Jan 17 09:38:39.489 2018] [7075] binlog: replay stats: 0 rows in 0 commits; 0 updates, 0 reconfigure; 0 indexes
[Wed Jan 17 09:38:39.489 2018] [7075] binlog: finished replaying /var/www/vhosts/elf925.com/sphinx/log/binlog.003; 0.0 MB in 0.000 sec
[Wed Jan 17 09:38:39.490 2018] [7075] binlog: replaying log /var/www/vhosts/elf925.com/sphinx/log/binlog.004
[Wed Jan 17 09:38:39.490 2018] [7075] binlog: replay stats: 0 rows in 0 commits; 0 updates, 0 reconfigure; 0 indexes
[Wed Jan 17 09:38:39.490 2018] [7075] binlog: finished replaying /var/www/vhosts/elf925.com/sphinx/log/binlog.004; 0.0 MB in 0.000 sec
[Wed Jan 17 09:38:39.490 2018] [7075] binlog: replaying log /var/www/vhosts/elf925.com/sphinx/log/binlog.005
[Wed Jan 17 09:38:39.490 2018] [7075] binlog: replay stats: 0 rows in 0 commits; 0 updates, 0 reconfigure; 0 indexes
[Wed Jan 17 09:38:39.490 2018] [7075] binlog: finished replaying /var/www/vhosts/elf925.com/sphinx/log/binlog.005; 0.0 MB in 0.000 sec
[Wed Jan 17 09:38:39.490 2018] [7075] binlog: replaying log /var/www/vhosts/elf925.com/sphinx/log/binlog.006
[Wed Jan 17 09:38:39.490 2018] [7075] binlog: replay stats: 0 rows in 0 commits; 0 updates, 0 reconfigure; 0 indexes
[Wed Jan 17 09:38:39.490 2018] [7075] binlog: finished replaying /var/www/vhosts/elf925.com/sphinx/log/binlog.006; 0.0 MB in 0.000 sec
[Wed Jan 17 09:38:39.490 2018] [7075] binlog: replaying log /var/www/vhosts/elf925.com/sphinx/log/binlog.007
[Wed Jan 17 09:38:39.490 2018] [7075] binlog: replay stats: 0 rows in 0 commits; 0 updates, 0 reconfigure; 0 indexes
[Wed Jan 17 09:38:39.490 2018] [7075] binlog: finished replaying /var/www/vhosts/elf925.com/sphinx/log/binlog.007; 0.0 MB in 0.000 sec
[Wed Jan 17 09:38:39.490 2018] [7075] binlog: replaying log /var/www/vhosts/elf925.com/sphinx/log/binlog.008
[Wed Jan 17 09:38:39.490 2018] [7075] binlog: replay stats: 0 rows in 0 commits; 0 updates, 0 reconfigure; 0 indexes
[Wed Jan 17 09:38:39.490 2018] [7075] binlog: finished replaying /var/www/vhosts/elf925.com/sphinx/log/binlog.008; 0.0 MB in 0.000 sec
[Wed Jan 17 09:38:39.490 2018] [7075] binlog: replaying log /var/www/vhosts/elf925.com/sphinx/log/binlog.009
[Wed Jan 17 09:38:39.490 2018] [7075] binlog: replay stats: 0 rows in 0 commits; 0 updates, 0 reconfigure; 0 indexes
[Wed Jan 17 09:38:39.490 2018] [7075] binlog: finished replaying /var/www/vhosts/elf925.com/sphinx/log/binlog.009; 0.0 MB in 0.000 sec
[Wed Jan 17 09:38:39.490 2018] [7075] binlog: replaying log /var/www/vhosts/elf925.com/sphinx/log/binlog.010
[Wed Jan 17 09:38:39.490 2018] [7075] binlog: replay stats: 0 rows in 0 commits; 0 updates, 0 reconfigure; 0 indexes
[Wed Jan 17 09:38:39.490 2018] [7075] binlog: finished replaying /var/www/vhosts/elf925.com/sphinx/log/binlog.010; 0.0 MB in 0.000 sec
[Wed Jan 17 09:38:39.490 2018] [7075] binlog: replaying log /var/www/vhosts/elf925.com/sphinx/log/binlog.011
[Wed Jan 17 09:38:39.490 2018] [7075] binlog: replay stats: 0 rows in 0 commits; 0 updates, 0 reconfigure; 0 indexes
[Wed Jan 17 09:38:39.490 2018] [7075] binlog: finished replaying /var/www/vhosts/elf925.com/sphinx/log/binlog.011; 0.0 MB in 0.000 sec
[Wed Jan 17 09:38:39.490 2018] [7075] binlog: replaying log /var/www/vhosts/elf925.com/sphinx/log/binlog.012
[Wed Jan 17 09:38:39.490 2018] [7075] binlog: replay stats: 0 rows in 0 commits; 0 updates, 0 reconfigure; 0 indexes
[Wed Jan 17 09:38:39.490 2018] [7075] binlog: finished replaying /var/www/vhosts/elf925.com/sphinx/log/binlog.012; 0.0 MB in 0.000 sec
[Wed Jan 17 09:38:39.490 2018] [7075] binlog: replaying log /var/www/vhosts/elf925.com/sphinx/log/binlog.012
[Wed Jan 17 09:38:39.490 2018] [7075] binlog: replay stats: 0 rows in 0 commits; 0 updates, 0 reconfigure; 0 indexes
[Wed Jan 17 09:38:39.490 2018] [7075] binlog: finished replaying /var/www/vhosts/elf925.com/sphinx/log/binlog.012; 0.0 MB in 0.000 sec
[Wed Jan 17 09:38:39.490 2018] [7075] binlog: replaying log /var/www/vhosts/elf925.com/sphinx/log/binlog.012
[Wed Jan 17 09:38:39.490 2018] [7075] binlog: replay stats: 0 rows in 0 commits; 0 updates, 0 reconfigure; 0 indexes
[Wed Jan 17 09:38:39.490 2018] [7075] binlog: finished replaying /var/www/vhosts/elf925.com/sphinx/log/binlog.012; 0.0 MB in 0.000 sec
[Wed Jan 17 09:38:39.490 2018] [7075] binlog: replaying log /var/www/vhosts/elf925.com/sphinx/log/binlog.013
[Wed Jan 17 09:38:39.490 2018] [7075] binlog: replay stats: 0 rows in 0 commits; 0 updates, 0 reconfigure; 0 indexes
[Wed Jan 17 09:38:39.490 2018] [7075] binlog: finished replaying /var/www/vhosts/elf925.com/sphinx/log/binlog.013; 0.0 MB in 0.000 sec
[Wed Jan 17 09:38:39.490 2018] [7075] binlog: replaying log /var/www/vhosts/elf925.com/sphinx/log/binlog.014
[Wed Jan 17 09:38:39.490 2018] [7075] binlog: replay stats: 0 rows in 0 commits; 0 updates, 0 reconfigure; 0 indexes
[Wed Jan 17 09:38:39.490 2018] [7075] binlog: finished replaying /var/www/vhosts/elf925.com/sphinx/log/binlog.014; 0.0 MB in 0.000 sec
[Wed Jan 17 09:38:39.490 2018] [7075] binlog: replaying log /var/www/vhosts/elf925.com/sphinx/log/binlog.015
[Wed Jan 17 09:38:39.490 2018] [7075] binlog: replay stats: 0 rows in 0 commits; 0 updates, 0 reconfigure; 0 indexes
[Wed Jan 17 09:38:39.490 2018] [7075] binlog: finished replaying /var/www/vhosts/elf925.com/sphinx/log/binlog.015; 0.0 MB in 0.000 sec
[Wed Jan 17 09:38:39.490 2018] [7075] binlog: finished replaying total 19 in 0.001 sec
[Wed Jan 17 09:38:39.491 2018] [7113] prereading 4 indexes
[Wed Jan 17 09:38:39.491 2018] [7075] accepting connections
[Wed Jan 17 09:38:39.549 2018] [7113] prereaded 4 indexes in 0.058 sec
[Wed Jan 17 10:02:20.175 2018] [7075] caught SIGHUP (seamless=1, in_rotate=0, need_rotate=0)
[Wed Jan 17 10:02:20.194 2018] [7106] rotating index 'delta': started
[Wed Jan 17 10:02:20.314 2018] [7106] WARNING: binlog: failed to unlink /var/www/vhosts/elf925.com/sphinx/log/binlog.003: No such file or directory (remove it manually)
[Wed Jan 17 10:02:20.400 2018] [7106] WARNING: last message repeated 1 times
[Wed Jan 17 10:02:20.400 2018] [7106] WARNING: binlog: failed to unlink /var/www/vhosts/elf925.com/sphinx/log/binlog.012: No such file or directory (remove it manually)
[Wed Jan 17 10:02:20.400 2018] [7106] WARNING: last message repeated 1 times
[Wed Jan 17 10:02:20.400 2018] [7106] WARNING: binlog: failed to unlink /var/www/vhosts/elf925.com/sphinx/log/binlog.015: No such file or directory (remove it manually)
[Wed Jan 17 10:02:20.405 2018] [7106] rotating index 'delta': success
[Wed Jan 17 10:02:20.405 2018] [7106] rotating index: all indexes done
[Wed Jan 17 10:02:22.548 2018] [7075] caught SIGHUP (seamless=1, in_rotate=0, need_rotate=0)
[Wed Jan 17 10:02:22.559 2018] [7106] rotating index 'main': started
[Wed Jan 17 10:02:22.641 2018] [7106] rotating index 'main': success
[Wed Jan 17 10:02:22.667 2018] [7106] rotating index: all indexes done
[Wed Jan 17 10:03:07.939 2018] [7075] caught SIGHUP (seamless=1, in_rotate=0, need_rotate=0)
[Wed Jan 17 10:03:07.952 2018] [7106] rotating index 'delta': started
[Wed Jan 17 10:03:07.988 2018] [7106] rotating index 'delta': success
[Wed Jan 17 10:03:07.988 2018] [7106] rotating index: all indexes done
[Wed Jan 17 10:03:08.918 2018] [7075] caught SIGHUP (seamless=1, in_rotate=0, need_rotate=0)
[Wed Jan 17 10:03:08.940 2018] [7106] rotating index 'main': started
[Wed Jan 17 10:03:09.010 2018] [7106] rotating index 'main': success
[Wed Jan 17 10:03:09.010 2018] [7106] rotating index: all indexes done
[Wed Jan 17 10:36:12.029 2018] [7075] caught SIGHUP (seamless=1, in_rotate=0, need_rotate=0)
[Wed Jan 17 10:36:12.049 2018] [7106] rotating index 'delta': started
[Wed Jan 17 10:36:12.102 2018] [7106] rotating index 'delta': success
[Wed Jan 17 10:36:12.102 2018] [7106] rotating index: all indexes done
[Wed Jan 17 10:36:13.025 2018] [7075] caught SIGHUP (seamless=1, in_rotate=0, need_rotate=0)
[Wed Jan 17 10:36:13.054 2018] [7106] rotating index 'main': started
[Wed Jan 17 10:36:13.124 2018] [7106] rotating index 'main': success
[Wed Jan 17 10:36:13.124 2018] [7106] rotating index: all indexes done
[Wed Jan 17 10:36:43.449 2018] [7075] caught SIGHUP (seamless=1, in_rotate=0, need_rotate=0)
[Wed Jan 17 10:36:43.482 2018] [7106] rotating index 'delta': started
[Wed Jan 17 10:36:43.536 2018] [7106] rotating index 'delta': success
[Wed Jan 17 10:36:43.536 2018] [7106] rotating index: all indexes done
[Wed Jan 17 10:36:44.372 2018] [7075] caught SIGHUP (seamless=1, in_rotate=0, need_rotate=0)
[Wed Jan 17 10:36:44.387 2018] [7106] rotating index 'main': started
[Wed Jan 17 10:36:44.486 2018] [7106] rotating index 'main': success
[Wed Jan 17 10:36:44.486 2018] [7106] rotating index: all indexes done
[Wed Jan 17 10:37:17.970 2018] [7075] caught SIGHUP (seamless=1, in_rotate=0, need_rotate=0)
[Wed Jan 17 10:37:17.999 2018] [7106] rotating index 'delta': started
[Wed Jan 17 10:37:18.034 2018] [7106] rotating index 'delta': success
[Wed Jan 17 10:37:18.047 2018] [7106] rotating index: all indexes done
[Wed Jan 17 10:37:18.950 2018] [7075] caught SIGHUP (seamless=1, in_rotate=0, need_rotate=0)
[Wed Jan 17 10:37:18.998 2018] [7106] rotating index 'main': started
[Wed Jan 17 10:37:19.083 2018] [7106] rotating index 'main': success
[Wed Jan 17 10:37:19.083 2018] [7106] rotating index: all indexes done
------- FATAL: CRASH DUMP -------
[Wed Jan 17 10:37:40.474 2018] [ 7075]

--- crashed SphinxAPI request dump ---
AAABHQAAAeMAAAAAAAAAAQAAAAAAAAAAAAABLAAAAAEAAAAHAAAAAQAAAA5kYXRlX2F2YWlsYWJsZQAAABMqR2Vt
IGpld2Vscnkgd29tZW4qAAAAAAAAAARtYWluAAAAAQAAAAAAAAAAAAAAAAAAAAAAAAAFAAAACHF1YW50
aXR5AAAAAQAAAAAAAAABAAAAAH/4nsAAAAAAAAAACnNvcnRfcHJpY2UAAAACAAAAAELIAAAAAAAAAAAA
BnN0YXR1cwAAAAAAAAABAAAAAAAAAAEAAAAAAAAADHN0b3JlX2ZpbHRlcgAAAAAAAAABAAAAAAAAAAAA
AAAAAAAAC2xhbmd1YWdlX2lkAAAAAAAAAAEAAAAAAAAAAQAAAAAAAAAAAAAAAAAAA+gAAAALQGdy
b3VwIGRlc2MAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAABwAAAARuYW1lAAAAAQAAAAtkZXNj
cmlwdGlvbgAAAAEAAAAFbW9kZWwAAAABAAAADGN1c3RvbV90aXRsZQAAAAEAAAADdGFnAAAAAQAAABBt
ZXRhX2Rlc2NyaXB0aW9uAAAAAQAAAAxtZXRhX2tleXdvcmQAAAABAAAAAAAAAAAAAAABKgAAAAAAAAAA
AAAAAAAAAAA=
--- request dump end ---
Sphinx 2.6.0 b84f229@171228 release
Handling signal 11
-------------- backtrace begins here ---------------
Program compiled with 4.7
Configured with flags: Configured by CMake with these definitions: -DCMAKE_BUILD_TYPE=RelWithDebInfo -DDISTR_BUILD=wheezy -DDL_UNIXODBC=1 -DUNIXODBC_LIB=libodbc.so.1 -DDL_EXPAT=1 -DEXPAT_LIB=libexpat.so.1 -DUSE_LIBICONV=1 -DDL_MYSQL=1 -DMYSQL_LIB=libmysqlclient.so.18 -DDL_PGSQL=1 -DPGSQL_LIB=libpq.so.5 -DDATADIR=/var/data -DSPLIT_SYMBOLS=ON -DUSE_BISON=ON -DUSE_FLEX=ON -DUSE_SYSLOG=1 -DWITH_EXPAT=ON -DWITH_ICONV=ON -DWITH_MYSQL=ON -DWITH_ODBC=ON -DWITH_PGSQL=ON -DWITH_RE2=ON -DWITH_STEMMER=ON -DWITH_ZLIB=ON -DSYSCONFDIR=/etc/sphinxsearch
Host OS is Linux f355da8a9849 4.8.0-45-generic #48~16.04.1-Ubuntu SMP Fri Mar 24 12:46:56 UTC 2017 x86_64 GNU/Linux
Stack bottom = 0x7f6bba89aeaf, thread stack size = 0x100000
Trying manual backtrace:
Something wrong with thread stack, manual backtrace may be incorrect (fp=0x4)
Wrong stack limit or frame pointer, manual backtrace failed (fp=0x4, stack=0x7f6bba8a0000, stacksize=0x100000)
Trying system backtrace:
[Wed Jan 17 10:37:40.767 2018] [7074] watchdog: main process 7075 killed dirtily with signal 11, will be restarted
[Wed Jan 17 10:37:40.767 2018] [7074] watchdog: main process 12752 forked ok
[Wed Jan 17 10:37:40.768 2018] [12752] listening on all interfaces, port=9313
[Wed Jan 17 10:37:40.768 2018] [12752] listening on all interfaces, port=9307
[Wed Jan 17 10:37:40.776 2018] [12752] binlog: replaying log /var/www/vhosts/elf925.com/sphinx/log/binlog.001
[Wed Jan 17 10:37:40.776 2018] [12752] binlog: replay stats: 0 rows in 0 commits; 0 updates, 0 reconfigure; 0 indexes
[Wed Jan 17 10:37:40.776 2018] [12752] binlog: finished replaying /var/www/vhosts/elf925.com/sphinx/log/binlog.001; 0.0 MB in 0.000 sec
[Wed Jan 17 10:37:40.776 2018] [12752] binlog: finished replaying total 1 in 0.000 sec
[Wed Jan 17 10:37:40.777 2018] [12790] prereading 4 indexes
[Wed Jan 17 10:37:40.777 2018] [12752] accepting connections
------- FATAL: CRASH DUMP -------
[Wed Jan 17 10:37:40.777 2018] [12752]

--- crashed SphinxAPI request dump ---
AAABHQAAAg8AAAAAAAAAAQAAAAAAAAAAAAABLAAAAAEAAAAHAAAAAQAAAA5kYXRlX2F2YWlsYWJsZQAAABMqR2Vt
IGpld2Vscnkgd29tZW4qAAAAAAAAAARtYWluAAAAAQAAAAAAAAAAAAAAAAAAAAAAAAACAAAACHF1YW50
aXR5AAAAAQAAAAAAAAABAAAAAH/4nsAAAAAAAAAABXByaWNlAAAAAgAAAABO//E+AAAAAAAAAAAAAAAA
AAAD6AAAAAtAZ3JvdXAgZGVzYwAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAHAAAABG5hbWUA
AAABAAAAC2Rlc2NyaXB0aW9uAAAAAQAAAAVtb2RlbAAAAAEAAAAMY3VzdG9tX3RpdGxlAAAAAQAA
AAN0YWcAAAABAAAAEG1ldGFfZGVzY3JpcHRpb24AAAABAAAADG1ldGFfa2V5d29yZAAAAAEAAAAAAAAA
AAAAAJcqLCBNSU4ocXVhbnRpdHkpIGFzIHNsaWRlcl9xdWFudGl0eV9taW4sIE1BWChxdWFudGl0eSkg
YXMgc2xpZGVyX3F1YW50aXR5X21heCwgTUlOKHNvcnRfcHJpY2UpIGFzIHNsaWRlcl9wcmljZV9taW4s
IE1BWChzb3J0X3ByaWNlKSBhcyBzbGlkZXJfcHJpY2VfbWF4AAAAAAAAAAAAAAAAAAAAAA==
--- request dump end ---
Sphinx 2.6.0 b84f229@171228 release
Handling signal 11
-------------- backtrace begins here ---------------
Program compiled with 4.7
Configured with flags: Configured by CMake with these definitions: -DCMAKE_BUILD_TYPE=RelWithDebInfo -DDISTR_BUILD=wheezy -DDL_UNIXODBC=1 -DUNIXODBC_LIB=libodbc.so.1 -DDL_EXPAT=1 -DEXPAT_LIB=libexpat.so.1 -DUSE_LIBICONV=1 -DDL_MYSQL=1 -DMYSQL_LIB=libmysqlclient.so.18 -DDL_PGSQL=1 -DPGSQL_LIB=libpq.so.5 -DDATADIR=/var/data -DSPLIT_SYMBOLS=ON -DUSE_BISON=ON -DUSE_FLEX=ON -DUSE_SYSLOG=1 -DWITH_EXPAT=ON -DWITH_ICONV=ON -DWITH_MYSQL=ON -DWITH_ODBC=ON -DWITH_PGSQL=ON -DWITH_RE2=ON -DWITH_STEMMER=ON -DWITH_ZLIB=ON -DSYSCONFDIR=/etc/sphinxsearch
Host OS is Linux f355da8a9849 4.8.0-45-generic #48~16.04.1-Ubuntu SMP Fri Mar 24 12:46:56 UTC 2017 x86_64 GNU/Linux
Stack bottom = 0x7f6bbb611eaf, thread stack size = 0x100000
Trying manual backtrace:
Something wrong with thread stack, manual backtrace may be incorrect (fp=0x4)
Wrong stack limit or frame pointer, manual backtrace failed (fp=0x4, stack=0x7f6bbb610000, stacksize=0x100000)
Trying system backtrace:
[Wed Jan 17 10:37:40.820 2018] [7074] watchdog: main process 12752 killed dirtily with signal 11, will be restarted
[Wed Jan 17 10:37:40.821 2018] [7074] watchdog: main process 12792 forked ok
[Wed Jan 17 10:37:40.822 2018] [12792] listening on all interfaces, port=9313
[Wed Jan 17 10:37:40.822 2018] [12792] listening on all interfaces, port=9307
[Wed Jan 17 10:37:40.830 2018] [12792] binlog: replaying log /var/www/vhosts/elf925.com/sphinx/log/binlog.001
[Wed Jan 17 10:37:40.830 2018] [12792] binlog: replay stats: 0 rows in 0 commits; 0 updates, 0 reconfigure; 0 indexes
[Wed Jan 17 10:37:40.830 2018] [12792] binlog: finished replaying /var/www/vhosts/elf925.com/sphinx/log/binlog.001; 0.0 MB in 0.000 sec
[Wed Jan 17 10:37:40.830 2018] [12792] binlog: replaying log /var/www/vhosts/elf925.com/sphinx/log/binlog.002
[Wed Jan 17 10:37:40.830 2018] [12792] WARNING: binlog: empty binlog /var/www/vhosts/elf925.com/sphinx/log/binlog.002 detected, skipping
[Wed Jan 17 10:37:40.830 2018] [12792] binlog: finished replaying total 2 in 0.000 sec
[Wed Jan 17 10:37:40.830 2018] [12830] prereading 4 indexes
[Wed Jan 17 10:37:40.830 2018] [12792] accepting connections
[Wed Jan 17 10:37:40.890 2018] [12830] prereaded 4 indexes in 0.059 sec
[Wed Jan 17 10:37:46.114 2018] [12792] caught SIGHUP (seamless=1, in_rotate=0, need_rotate=0)
[Wed Jan 17 10:37:46.139 2018] [12823] rotating index 'delta': started
[Wed Jan 17 10:37:46.161 2018] [12823] WARNING: binlog: failed to unlink /var/www/vhosts/elf925.com/sphinx/log/binlog.002: No such file or directory (remove it manually)
[Wed Jan 17 10:37:46.171 2018] [12823] rotating index 'delta': success
[Wed Jan 17 10:37:46.172 2018] [12823] rotating index: all indexes done
------- FATAL: CRASH DUMP -------
[Wed Jan 17 10:38:18.649 2018] [12792]

--- crashed SphinxAPI request dump ---
AAABHQAAAeMAAAAAAAAAAQAAAAAAAASwAAABLAAAAAEAAAAHAAAAAQAAAA5kYXRlX2F2YWlsYWJsZQAAABMqR2Vt
IGpld2Vscnkgd29tZW4qAAAAAAAAAARtYWluAAAAAQAAAAAAAAAAAAAAAAAAAAAAAAAFAAAACHF1YW50
aXR5AAAAAQAAAAAAAAABAAAAAH/4nsAAAAAAAAAACnNvcnRfcHJpY2UAAAACAAAAAELIAAAAAAAAAAAA
BnN0YXR1cwAAAAAAAAABAAAAAAAAAAEAAAAAAAAADHN0b3JlX2ZpbHRlcgAAAAAAAAABAAAAAAAAAAAA
AAAAAAAAC2xhbmd1YWdlX2lkAAAAAAAAAAEAAAAAAAAAAQAAAAAAAAAAAAAAAAAAB9AAAAALQGdy
b3VwIGRlc2MAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAABwAAAARuYW1lAAAAAQAAAAtkZXNj
cmlwdGlvbgAAAAEAAAAFbW9kZWwAAAABAAAADGN1c3RvbV90aXRsZQAAAAEAAAADdGFnAAAAAQAAABBt
ZXRhX2Rlc2NyaXB0aW9uAAAAAQAAAAxtZXRhX2tleXdvcmQAAAABAAAAAAAAAAAAAAABKgAAAAAAAAAA
AAAAAAAAAAA=
--- request dump end ---
Sphinx 2.6.0 b84f229@171228 release
Handling signal 11
-------------- backtrace begins here ---------------
Program compiled with 4.7
Configured with flags: Configured by CMake with these definitions: -DCMAKE_BUILD_TYPE=RelWithDebInfo -DDISTR_BUILD=wheezy -DDL_UNIXODBC=1 -DUNIXODBC_LIB=libodbc.so.1 -DDL_EXPAT=1 -DEXPAT_LIB=libexpat.so.1 -DUSE_LIBICONV=1 -DDL_MYSQL=1 -DMYSQL_LIB=libmysqlclient.so.18 -DDL_PGSQL=1 -DPGSQL_LIB=libpq.so.5 -DDATADIR=/var/data -DSPLIT_SYMBOLS=ON -DUSE_BISON=ON -DUSE_FLEX=ON -DUSE_SYSLOG=1 -DWITH_EXPAT=ON -DWITH_ICONV=ON -DWITH_MYSQL=ON -DWITH_ODBC=ON -DWITH_PGSQL=ON -DWITH_RE2=ON -DWITH_STEMMER=ON -DWITH_ZLIB=ON -DSYSCONFDIR=/etc/sphinxsearch
Host OS is Linux f355da8a9849 4.8.0-45-generic #48~16.04.1-Ubuntu SMP Fri Mar 24 12:46:56 UTC 2017 x86_64 GNU/Linux
Stack bottom = 0x7f6bbadf1eaf, thread stack size = 0x100000
Trying manual backtrace:
Something wrong with thread stack, manual backtrace may be incorrect (fp=0x4)
Wrong stack limit or frame pointer, manual backtrace failed (fp=0x4, stack=0x7f6bbadf0000, stacksize=0x100000)
Trying system backtrace:
[Wed Jan 17 10:38:19.104 2018] [7074] watchdog: main process 12792 killed dirtily with signal 11, will be restarted
[Wed Jan 17 10:38:19.104 2018] [7074] watchdog: main process 12913 forked ok
[Wed Jan 17 10:38:19.105 2018] [12913] listening on all interfaces, port=9313
[Wed Jan 17 10:38:19.106 2018] [12913] listening on all interfaces, port=9307
[Wed Jan 17 10:38:19.113 2018] [12913] binlog: replaying log /var/www/vhosts/elf925.com/sphinx/log/binlog.001
[Wed Jan 17 10:38:19.113 2018] [12913] binlog: replay stats: 0 rows in 0 commits; 0 updates, 0 reconfigure; 0 indexes
[Wed Jan 17 10:38:19.113 2018] [12913] binlog: finished replaying /var/www/vhosts/elf925.com/sphinx/log/binlog.001; 0.0 MB in 0.000 sec
[Wed Jan 17 10:38:19.113 2018] [12913] binlog: finished replaying total 1 in 0.000 sec
[Wed Jan 17 10:38:19.114 2018] [12951] prereading 4 indexes
[Wed Jan 17 10:38:19.114 2018] [12913] accepting connections
[Wed Jan 17 10:38:19.175 2018] [12951] prereaded 4 indexes in 0.061 sec
[Wed Jan 17 10:38:20.477 2018] [12913] caught SIGHUP (seamless=1, in_rotate=0, need_rotate=0)
[Wed Jan 17 10:38:20.516 2018] [12944] rotating index 'delta': started
[Wed Jan 17 10:38:20.584 2018] [12944] rotating index 'delta': success
[Wed Jan 17 10:38:20.584 2018] [12944] rotating index: all indexes done
------- FATAL: CRASH DUMP -------
[Wed Jan 17 10:38:29.988 2018] [12913]

--- crashed SphinxAPI request dump ---
AAABHQAAAeMAAAAAAAAAAQAAAAAAAAAAAAABLAAAAAEAAAAHAAAAAQAAAA5kYXRlX2F2YWlsYWJsZQAAABMqR2Vt
IGpld2Vscnkgd29tZW4qAAAAAAAAAARtYWluAAAAAQAAAAAAAAAAAAAAAAAAAAAAAAAFAAAACHF1YW50
aXR5AAAAAQAAAAAAAAABAAAAAH/4nsAAAAAAAAAACnNvcnRfcHJpY2UAAAACAAAAAELIAAAAAAAAAAAA
BnN0YXR1cwAAAAAAAAABAAAAAAAAAAEAAAAAAAAADHN0b3JlX2ZpbHRlcgAAAAAAAAABAAAAAAAAAAAA
AAAAAAAAC2xhbmd1YWdlX2lkAAAAAAAAAAEAAAAAAAAAAQAAAAAAAAAAAAAAAAAAA+gAAAALQGdy
b3VwIGRlc2MAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAABwAAAARuYW1lAAAAAQAAAAtkZXNj
cmlwdGlvbgAAAAEAAAAFbW9kZWwAAAABAAAADGN1c3RvbV90aXRsZQAAAAEAAAADdGFnAAAAAQAAABBt
ZXRhX2Rlc2NyaXB0aW9uAAAAAQAAAAxtZXRhX2tleXdvcmQAAAABAAAAAAAAAAAAAAABKgAAAAAAAAAA
AAAAAAAAAAA=
--- request dump end ---
Sphinx 2.6.0 b84f229@171228 release
Handling signal 11
-------------- backtrace begins here ---------------
Program compiled with 4.7
Configured with flags: Configured by CMake with these definitions: -DCMAKE_BUILD_TYPE=RelWithDebInfo -DDISTR_BUILD=wheezy -DDL_UNIXODBC=1 -DUNIXODBC_LIB=libodbc.so.1 -DDL_EXPAT=1 -DEXPAT_LIB=libexpat.so.1 -DUSE_LIBICONV=1 -DDL_MYSQL=1 -DMYSQL_LIB=libmysqlclient.so.18 -DDL_PGSQL=1 -DPGSQL_LIB=libpq.so.5 -DDATADIR=/var/data -DSPLIT_SYMBOLS=ON -DUSE_BISON=ON -DUSE_FLEX=ON -DUSE_SYSLOG=1 -DWITH_EXPAT=ON -DWITH_ICONV=ON -DWITH_MYSQL=ON -DWITH_ODBC=ON -DWITH_PGSQL=ON -DWITH_RE2=ON -DWITH_STEMMER=ON -DWITH_ZLIB=ON -DSYSCONFDIR=/etc/sphinxsearch
Host OS is Linux f355da8a9849 4.8.0-45-generic #48~16.04.1-Ubuntu SMP Fri Mar 24 12:46:56 UTC 2017 x86_64 GNU/Linux
Stack bottom = 0x7f6bbb50deaf, thread stack size = 0x100000
Trying manual backtrace:
Something wrong with thread stack, manual backtrace may be incorrect (fp=0x4)
Wrong stack limit or frame pointer, manual backtrace failed (fp=0x4, stack=0x7f6bbb510000, stacksize=0x100000)
Trying system backtrace:
[Wed Jan 17 10:38:30.050 2018] [7074] watchdog: main process 12913 killed dirtily with signal 11, will be restarted
[Wed Jan 17 10:38:30.051 2018] [7074] watchdog: main process 12957 forked ok
[Wed Jan 17 10:38:30.052 2018] [12957] listening on all interfaces, port=9313
[Wed Jan 17 10:38:30.052 2018] [12957] listening on all interfaces, port=9307
[Wed Jan 17 10:38:30.060 2018] [12957] binlog: replaying log /var/www/vhosts/elf925.com/sphinx/log/binlog.001
[Wed Jan 17 10:38:30.060 2018] [12957] binlog: replay stats: 0 rows in 0 commits; 0 updates, 0 reconfigure; 0 indexes
[Wed Jan 17 10:38:30.060 2018] [12957] binlog: finished replaying /var/www/vhosts/elf925.com/sphinx/log/binlog.001; 0.0 MB in 0.000 sec
[Wed Jan 17 10:38:30.060 2018] [12957] binlog: finished replaying total 1 in 0.000 sec
[Wed Jan 17 10:38:30.060 2018] [12995] prereading 4 indexes
[Wed Jan 17 10:38:30.060 2018] [12957] accepting connections
[Wed Jan 17 10:38:30.121 2018] [12995] prereaded 4 indexes in 0.061 sec
[Wed Jan 17 10:38:44.904 2018] [12957] caught SIGHUP (seamless=1, in_rotate=0, need_rotate=0)
[Wed Jan 17 10:38:44.936 2018] [12988] rotating index 'delta': started
[Wed Jan 17 10:38:44.969 2018] [12988] rotating index 'delta': success
[Wed Jan 17 10:38:44.969 2018] [12988] rotating index: all indexes done
------- FATAL: CRASH DUMP -------
[Wed Jan 17 10:39:05.923 2018] [12957]

--- crashed SphinxAPI request dump ---
AAABHQAAAeMAAAAAAAAAAQAAAAAAAASwAAABLAAAAAEAAAAHAAAAAQAAAA5kYXRlX2F2YWlsYWJsZQAAABMqR2Vt
IGpld2Vscnkgd29tZW4qAAAAAAAAAARtYWluAAAAAQAAAAAAAAAAAAAAAAAAAAAAAAAFAAAACHF1YW50
aXR5AAAAAQAAAAAAAAABAAAAAH/4nsAAAAAAAAAACnNvcnRfcHJpY2UAAAACAAAAAELIAAAAAAAAAAAA
BnN0YXR1cwAAAAAAAAABAAAAAAAAAAEAAAAAAAAADHN0b3JlX2ZpbHRlcgAAAAAAAAABAAAAAAAAAAAA
AAAAAAAAC2xhbmd1YWdlX2lkAAAAAAAAAAEAAAAAAAAAAQAAAAAAAAAAAAAAAAAAB9AAAAALQGdy
b3VwIGRlc2MAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAABwAAAARuYW1lAAAAAQAAAAtkZXNj
cmlwdGlvbgAAAAEAAAAFbW9kZWwAAAABAAAADGN1c3RvbV90aXRsZQAAAAEAAAADdGFnAAAAAQAAABBt
ZXRhX2Rlc2NyaXB0aW9uAAAAAQAAAAxtZXRhX2tleXdvcmQAAAABAAAAAAAAAAAAAAABKgAAAAAAAAAA
AAAAAAAAAAA=
--- request dump end ---
Sphinx 2.6.0 b84f229@171228 release
Handling signal 11
-------------- backtrace begins here ---------------
Program compiled with 4.7
Configured with flags: Configured by CMake with these definitions: -DCMAKE_BUILD_TYPE=RelWithDebInfo -DDISTR_BUILD=wheezy -DDL_UNIXODBC=1 -DUNIXODBC_LIB=libodbc.so.1 -DDL_EXPAT=1 -DEXPAT_LIB=libexpat.so.1 -DUSE_LIBICONV=1 -DDL_MYSQL=1 -DMYSQL_LIB=libmysqlclient.so.18 -DDL_PGSQL=1 -DPGSQL_LIB=libpq.so.5 -DDATADIR=/var/data -DSPLIT_SYMBOLS=ON -DUSE_BISON=ON -DUSE_FLEX=ON -DUSE_SYSLOG=1 -DWITH_EXPAT=ON -DWITH_ICONV=ON -DWITH_MYSQL=ON -DWITH_ODBC=ON -DWITH_PGSQL=ON -DWITH_RE2=ON -DWITH_STEMMER=ON -DWITH_ZLIB=ON -DSYSCONFDIR=/etc/sphinxsearch
Host OS is Linux f355da8a9849 4.8.0-45-generic #48~16.04.1-Ubuntu SMP Fri Mar 24 12:46:56 UTC 2017 x86_64 GNU/Linux
Stack bottom = 0x7f6bba5d1eaf, thread stack size = 0x100000
Trying manual backtrace:
Something wrong with thread stack, manual backtrace may be incorrect (fp=0x4)
Wrong stack limit or frame pointer, manual backtrace failed (fp=0x4, stack=0x7f6bba5d0000, stacksize=0x100000)
Trying system backtrace:
[Wed Jan 17 10:39:06.356 2018] [7074] watchdog: main process 12957 killed dirtily with signal 11, will be restarted
[Wed Jan 17 10:39:06.356 2018] [7074] watchdog: main process 13094 forked ok
[Wed Jan 17 10:39:06.357 2018] [13094] listening on all interfaces, port=9313
[Wed Jan 17 10:39:06.357 2018] [13094] listening on all interfaces, port=9307
[Wed Jan 17 10:39:06.365 2018] [13094] binlog: replaying log /var/www/vhosts/elf925.com/sphinx/log/binlog.001
[Wed Jan 17 10:39:06.365 2018] [13094] binlog: replay stats: 0 rows in 0 commits; 0 updates, 0 reconfigure; 0 indexes
[Wed Jan 17 10:39:06.365 2018] [13094] binlog: finished replaying /var/www/vhosts/elf925.com/sphinx/log/binlog.001; 0.0 MB in 0.000 sec
[Wed Jan 17 10:39:06.365 2018] [13094] binlog: finished replaying total 1 in 0.000 sec
[Wed Jan 17 10:39:06.365 2018] [13132] prereading 4 indexes
[Wed Jan 17 10:39:06.365 2018] [13094] accepting connections
------- FATAL: CRASH DUMP -------
[Wed Jan 17 10:39:06.365 2018] [13094]

--- crashed SphinxAPI request dump ---
AAABHQAAAg8AAAAAAAAAAQAAAAAAAAAAAAABLAAAAAEAAAAHAAAAAQAAAA5kYXRlX2F2YWlsYWJsZQAAABMqR2Vt
IGpld2Vscnkgd29tZW4qAAAAAAAAAARtYWluAAAAAQAAAAAAAAAAAAAAAAAAAAAAAAACAAAACHF1YW50
aXR5AAAAAQAAAAAAAAABAAAAAH/4nsAAAAAAAAAABXByaWNlAAAAAgAAAABO//E+AAAAAAAAAAAAAAAA
AAAD6AAAAAtAZ3JvdXAgZGVzYwAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAHAAAABG5hbWUA
AAABAAAAC2Rlc2NyaXB0aW9uAAAAAQAAAAVtb2RlbAAAAAEAAAAMY3VzdG9tX3RpdGxlAAAAAQAA
AAN0YWcAAAABAAAAEG1ldGFfZGVzY3JpcHRpb24AAAABAAAADG1ldGFfa2V5d29yZAAAAAEAAAAAAAAA
AAAAAJcqLCBNSU4ocXVhbnRpdHkpIGFzIHNsaWRlcl9xdWFudGl0eV9taW4sIE1BWChxdWFudGl0eSkg
YXMgc2xpZGVyX3F1YW50aXR5X21heCwgTUlOKHNvcnRfcHJpY2UpIGFzIHNsaWRlcl9wcmljZV9taW4s
IE1BWChzb3J0X3ByaWNlKSBhcyBzbGlkZXJfcHJpY2VfbWF4AAAAAAAAAAAAAAAAAAAAAA==
--- request dump end ---
Sphinx 2.6.0 b84f229@171228 release
Handling signal 11
-------------- backtrace begins here ---------------
Program compiled with 4.7
Configured with flags: Configured by CMake with these definitions: -DCMAKE_BUILD_TYPE=RelWithDebInfo -DDISTR_BUILD=wheezy -DDL_UNIXODBC=1 -DUNIXODBC_LIB=libodbc.so.1 -DDL_EXPAT=1 -DEXPAT_LIB=libexpat.so.1 -DUSE_LIBICONV=1 -DDL_MYSQL=1 -DMYSQL_LIB=libmysqlclient.so.18 -DDL_PGSQL=1 -DPGSQL_LIB=libpq.so.5 -DDATADIR=/var/data -DSPLIT_SYMBOLS=ON -DUSE_BISON=ON -DUSE_FLEX=ON -DUSE_SYSLOG=1 -DWITH_EXPAT=ON -DWITH_ICONV=ON -DWITH_MYSQL=ON -DWITH_ODBC=ON -DWITH_PGSQL=ON -DWITH_RE2=ON -DWITH_STEMMER=ON -DWITH_ZLIB=ON -DSYSCONFDIR=/etc/sphinxsearch
Host OS is Linux f355da8a9849 4.8.0-45-generic #48~16.04.1-Ubuntu SMP Fri Mar 24 12:46:56 UTC 2017 x86_64 GNU/Linux
Stack bottom = 0x7f6bbb50deaf, thread stack size = 0x100000
Trying manual backtrace:
Something wrong with thread stack, manual backtrace may be incorrect (fp=0x4)
Wrong stack limit or frame pointer, manual backtrace failed (fp=0x4, stack=0x7f6bbb510000, stacksize=0x100000)
Trying system backtrace:
[Wed Jan 17 10:39:06.375 2018] [7074] watchdog: main process 13094 killed dirtily with signal 11, will be restarted
[Wed Jan 17 10:39:06.376 2018] [7074] watchdog: main process 13134 forked ok
[Wed Jan 17 10:39:06.377 2018] [13134] listening on all interfaces, port=9313
[Wed Jan 17 10:39:06.377 2018] [13134] listening on all interfaces, port=9307
[Wed Jan 17 10:39:06.384 2018] [13134] binlog: replaying log /var/www/vhosts/elf925.com/sphinx/log/binlog.001
[Wed Jan 17 10:39:06.384 2018] [13134] binlog: replay stats: 0 rows in 0 commits; 0 updates, 0 reconfigure; 0 indexes
[Wed Jan 17 10:39:06.384 2018] [13134] binlog: finished replaying /var/www/vhosts/elf925.com/sphinx/log/binlog.001; 0.0 MB in 0.000 sec
[Wed Jan 17 10:39:06.384 2018] [13134] binlog: replaying log /var/www/vhosts/elf925.com/sphinx/log/binlog.002
[Wed Jan 17 10:39:06.384 2018] [13134] WARNING: binlog: empty binlog /var/www/vhosts/elf925.com/sphinx/log/binlog.002 detected, skipping
[Wed Jan 17 10:39:06.384 2018] [13134] binlog: finished replaying total 2 in 0.000 sec
[Wed Jan 17 10:39:06.385 2018] [13172] prereading 4 indexes
[Wed Jan 17 10:39:06.385 2018] [13134] accepting connections
[Wed Jan 17 10:39:06.445 2018] [13172] prereaded 4 indexes in 0.061 sec
------- FATAL: CRASH DUMP -------
[Wed Jan 17 10:39:11.890 2018] [13134]

--- crashed SphinxAPI request dump ---
AAABHQAAAeMAAAAAAAAAAQAAAAAAAAOEAAABLAAAAAEAAAAHAAAAAQAAAA5kYXRlX2F2YWlsYWJsZQAAABMqR2Vt
IGpld2Vscnkgd29tZW4qAAAAAAAAAARtYWluAAAAAQAAAAAAAAAAAAAAAAAAAAAAAAAFAAAACHF1YW50
aXR5AAAAAQAAAAAAAAABAAAAAH/4nsAAAAAAAAAACnNvcnRfcHJpY2UAAAACAAAAAELIAAAAAAAAAAAA
BnN0YXR1cwAAAAAAAAABAAAAAAAAAAEAAAAAAAAADHN0b3JlX2ZpbHRlcgAAAAAAAAABAAAAAAAAAAAA
AAAAAAAAC2xhbmd1YWdlX2lkAAAAAAAAAAEAAAAAAAAAAQAAAAAAAAAAAAAAAAAAB9AAAAALQGdy
b3VwIGRlc2MAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAABwAAAARuYW1lAAAAAQAAAAtkZXNj
cmlwdGlvbgAAAAEAAAAFbW9kZWwAAAABAAAADGN1c3RvbV90aXRsZQAAAAEAAAADdGFnAAAAAQAAABBt
ZXRhX2Rlc2NyaXB0aW9uAAAAAQAAAAxtZXRhX2tleXdvcmQAAAABAAAAAAAAAAAAAAABKgAAAAAAAAAA
AAAAAAAAAAA=
--- request dump end ---
Sphinx 2.6.0 b84f229@171228 release
Handling signal 11
-------------- backtrace begins here ---------------
Program compiled with 4.7
Configured with flags: Configured by CMake with these definitions: -DCMAKE_BUILD_TYPE=RelWithDebInfo -DDISTR_BUILD=wheezy -DDL_UNIXODBC=1 -DUNIXODBC_LIB=libodbc.so.1 -DDL_EXPAT=1 -DEXPAT_LIB=libexpat.so.1 -DUSE_LIBICONV=1 -DDL_MYSQL=1 -DMYSQL_LIB=libmysqlclient.so.18 -DDL_PGSQL=1 -DPGSQL_LIB=libpq.so.5 -DDATADIR=/var/data -DSPLIT_SYMBOLS=ON -DUSE_BISON=ON -DUSE_FLEX=ON -DUSE_SYSLOG=1 -DWITH_EXPAT=ON -DWITH_ICONV=ON -DWITH_MYSQL=ON -DWITH_ODBC=ON -DWITH_PGSQL=ON -DWITH_RE2=ON -DWITH_STEMMER=ON -DWITH_ZLIB=ON -DSYSCONFDIR=/etc/sphinxsearch
Host OS is Linux f355da8a9849 4.8.0-45-generic #48~16.04.1-Ubuntu SMP Fri Mar 24 12:46:56 UTC 2017 x86_64 GNU/Linux
Stack bottom = 0x7f6bbb201eaf, thread stack size = 0x100000
Trying manual backtrace:
Something wrong with thread stack, manual backtrace may be incorrect (fp=0x4)
Wrong stack limit or frame pointer, manual backtrace failed (fp=0x4, stack=0x7f6bbb200000, stacksize=0x100000)
Trying system backtrace:
[Wed Jan 17 10:39:12.007 2018] [7074] watchdog: main process 13134 killed dirtily with signal 11, will be restarted
[Wed Jan 17 10:39:12.007 2018] [7074] watchdog: main process 13176 forked ok
[Wed Jan 17 10:39:12.008 2018] [13176] listening on all interfaces, port=9313
[Wed Jan 17 10:39:12.009 2018] [13176] listening on all interfaces, port=9307
[Wed Jan 17 10:39:12.016 2018] [13176] binlog: replaying log /var/www/vhosts/elf925.com/sphinx/log/binlog.001
[Wed Jan 17 10:39:12.016 2018] [13176] binlog: replay stats: 0 rows in 0 commits; 0 updates, 0 reconfigure; 0 indexes
[Wed Jan 17 10:39:12.016 2018] [13176] binlog: finished replaying /var/www/vhosts/elf925.com/sphinx/log/binlog.001; 0.0 MB in 0.000 sec
[Wed Jan 17 10:39:12.016 2018] [13176] binlog: replaying log /var/www/vhosts/elf925.com/sphinx/log/binlog.002
[Wed Jan 17 10:39:12.016 2018] [13176] binlog: replay stats: 0 rows in 0 commits; 0 updates, 0 reconfigure; 0 indexes
[Wed Jan 17 10:39:12.016 2018] [13176] binlog: finished replaying /var/www/vhosts/elf925.com/sphinx/log/binlog.002; 0.0 MB in 0.000 sec
[Wed Jan 17 10:39:12.016 2018] [13176] binlog: replaying log /var/www/vhosts/elf925.com/sphinx/log/binlog.002
[Wed Jan 17 10:39:12.016 2018] [13176] binlog: replay stats: 0 rows in 0 commits; 0 updates, 0 reconfigure; 0 indexes
[Wed Jan 17 10:39:12.016 2018] [13176] binlog: finished replaying /var/www/vhosts/elf925.com/sphinx/log/binlog.002; 0.0 MB in 0.000 sec
[Wed Jan 17 10:39:12.016 2018] [13176] binlog: finished replaying total 3 in 0.000 sec
[Wed Jan 17 10:39:12.017 2018] [13214] prereading 4 indexes
[Wed Jan 17 10:39:12.017 2018] [13176] accepting connections
[Wed Jan 17 10:39:12.076 2018] [13214] prereaded 4 indexes in 0.059 sec
------- FATAL: CRASH DUMP -------
[Wed Jan 17 10:39:18.524 2018] [13176]

--- crashed SphinxAPI request dump ---
AAABHQAAAeMAAAAAAAAAAQAAAAAAAAJYAAABLAAAAAEAAAAHAAAAAQAAAA5kYXRlX2F2YWlsYWJsZQAAABMqR2Vt
IGpld2Vscnkgd29tZW4qAAAAAAAAAARtYWluAAAAAQAAAAAAAAAAAAAAAAAAAAAAAAAFAAAACHF1YW50
aXR5AAAAAQAAAAAAAAABAAAAAH/4nsAAAAAAAAAACnNvcnRfcHJpY2UAAAACAAAAAELIAAAAAAAAAAAA
BnN0YXR1cwAAAAAAAAABAAAAAAAAAAEAAAAAAAAADHN0b3JlX2ZpbHRlcgAAAAAAAAABAAAAAAAAAAAA
AAAAAAAAC2xhbmd1YWdlX2lkAAAAAAAAAAEAAAAAAAAAAQAAAAAAAAAAAAAAAAAAA+gAAAALQGdy
b3VwIGRlc2MAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAABwAAAARuYW1lAAAAAQAAAAtkZXNj
cmlwdGlvbgAAAAEAAAAFbW9kZWwAAAABAAAADGN1c3RvbV90aXRsZQAAAAEAAAADdGFnAAAAAQAAABBt
ZXRhX2Rlc2NyaXB0aW9uAAAAAQAAAAxtZXRhX2tleXdvcmQAAAABAAAAAAAAAAAAAAABKgAAAAAAAAAA
AAAAAAAAAAA=
--- request dump end ---
Sphinx 2.6.0 b84f229@171228 release
Handling signal 11
-------------- backtrace begins here ---------------
Program compiled with 4.7
Configured with flags: Configured by CMake with these definitions: -DCMAKE_BUILD_TYPE=RelWithDebInfo -DDISTR_BUILD=wheezy -DDL_UNIXODBC=1 -DUNIXODBC_LIB=libodbc.so.1 -DDL_EXPAT=1 -DEXPAT_LIB=libexpat.so.1 -DUSE_LIBICONV=1 -DDL_MYSQL=1 -DMYSQL_LIB=libmysqlclient.so.18 -DDL_PGSQL=1 -DPGSQL_LIB=libpq.so.5 -DDATADIR=/var/data -DSPLIT_SYMBOLS=ON -DUSE_BISON=ON -DUSE_FLEX=ON -DUSE_SYSLOG=1 -DWITH_EXPAT=ON -DWITH_ICONV=ON -DWITH_MYSQL=ON -DWITH_ODBC=ON -DWITH_PGSQL=ON -DWITH_RE2=ON -DWITH_STEMMER=ON -DWITH_ZLIB=ON -DSYSCONFDIR=/etc/sphinxsearch
Host OS is Linux f355da8a9849 4.8.0-45-generic #48~16.04.1-Ubuntu SMP Fri Mar 24 12:46:56 UTC 2017 x86_64 GNU/Linux
Stack bottom = 0x7f6bbb0fdeaf, thread stack size = 0x100000
Trying manual backtrace:
Something wrong with thread stack, manual backtrace may be incorrect (fp=0x4)
Wrong stack limit or frame pointer, manual backtrace failed (fp=0x4, stack=0x7f6bbb100000, stacksize=0x100000)
Trying system backtrace:
[Wed Jan 17 10:39:19.029 2018] [7074] watchdog: main process 13176 killed dirtily with signal 11, will be restarted
[Wed Jan 17 10:39:19.029 2018] [7074] watchdog: main process 13219 forked ok
[Wed Jan 17 10:39:19.030 2018] [13219] listening on all interfaces, port=9313
[Wed Jan 17 10:39:19.030 2018] [13219] listening on all interfaces, port=9307
[Wed Jan 17 10:39:19.038 2018] [13219] binlog: replaying log /var/www/vhosts/elf925.com/sphinx/log/binlog.001
[Wed Jan 17 10:39:19.038 2018] [13219] binlog: replay stats: 0 rows in 0 commits; 0 updates, 0 reconfigure; 0 indexes
[Wed Jan 17 10:39:19.038 2018] [13219] binlog: finished replaying /var/www/vhosts/elf925.com/sphinx/log/binlog.001; 0.0 MB in 0.000 sec
[Wed Jan 17 10:39:19.038 2018] [13219] binlog: replaying log /var/www/vhosts/elf925.com/sphinx/log/binlog.002
[Wed Jan 17 10:39:19.038 2018] [13219] binlog: replay stats: 0 rows in 0 commits; 0 updates, 0 reconfigure; 0 indexes
[Wed Jan 17 10:39:19.038 2018] [13219] binlog: finished replaying /var/www/vhosts/elf925.com/sphinx/log/binlog.002; 0.0 MB in 0.000 sec
[Wed Jan 17 10:39:19.038 2018] [13219] binlog: replaying log /var/www/vhosts/elf925.com/sphinx/log/binlog.002
[Wed Jan 17 10:39:19.038 2018] [13219] binlog: replay stats: 0 rows in 0 commits; 0 updates, 0 reconfigure; 0 indexes
[Wed Jan 17 10:39:19.038 2018] [13219] binlog: finished replaying /var/www/vhosts/elf925.com/sphinx/log/binlog.002; 0.0 MB in 0.000 sec
[Wed Jan 17 10:39:19.038 2018] [13219] binlog: replaying log /var/www/vhosts/elf925.com/sphinx/log/binlog.003
[Wed Jan 17 10:39:19.038 2018] [13219] binlog: replay stats: 0 rows in 0 commits; 0 updates, 0 reconfigure; 0 indexes
[Wed Jan 17 10:39:19.038 2018] [13219] binlog: finished replaying /var/www/vhosts/elf925.com/sphinx/log/binlog.003; 0.0 MB in 0.000 sec
[Wed Jan 17 10:39:19.038 2018] [13219] binlog: finished replaying total 4 in 0.000 sec
[Wed Jan 17 10:39:19.039 2018] [13257] prereading 4 indexes
[Wed Jan 17 10:39:19.039 2018] [13219] accepting connections
[Wed Jan 17 10:39:19.100 2018] [13257] prereaded 4 indexes in 0.061 sec
------- FATAL: CRASH DUMP -------
[Wed Jan 17 10:39:26.047 2018] [13219]

--- crashed SphinxAPI request dump ---
AAABHQAAAeMAAAAAAAAAAQAAAAAAAAAAAAABLAAAAAEAAAAHAAAAAQAAAA5kYXRlX2F2YWlsYWJsZQAAABMqR2Vt
IGpld2Vscnkgd29tZW4qAAAAAAAAAARtYWluAAAAAQAAAAAAAAAAAAAAAAAAAAAAAAAFAAAACHF1YW50
aXR5AAAAAQAAAAAAAAABAAAAAH/4nsAAAAAAAAAACnNvcnRfcHJpY2UAAAACAAAAAELIAAAAAAAAAAAA
BnN0YXR1cwAAAAAAAAABAAAAAAAAAAEAAAAAAAAADHN0b3JlX2ZpbHRlcgAAAAAAAAABAAAAAAAAAAAA
AAAAAAAAC2xhbmd1YWdlX2lkAAAAAAAAAAEAAAAAAAAAAQAAAAAAAAAAAAAAAAAAA+gAAAALQGdy
b3VwIGRlc2MAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAABwAAAARuYW1lAAAAAQAAAAtkZXNj
cmlwdGlvbgAAAAEAAAAFbW9kZWwAAAABAAAADGN1c3RvbV90aXRsZQAAAAEAAAADdGFnAAAAAQAAABBt
ZXRhX2Rlc2NyaXB0aW9uAAAAAQAAAAxtZXRhX2tleXdvcmQAAAABAAAAAAAAAAAAAAABKgAAAAAAAAAA
AAAAAAAAAAA=
--- request dump end ---
Sphinx 2.6.0 b84f229@171228 release
Handling signal 11
-------------- backtrace begins here ---------------
Program compiled with 4.7
Configured with flags: Configured by CMake with these definitions: -DCMAKE_BUILD_TYPE=RelWithDebInfo -DDISTR_BUILD=wheezy -DDL_UNIXODBC=1 -DUNIXODBC_LIB=libodbc.so.1 -DDL_EXPAT=1 -DEXPAT_LIB=libexpat.so.1 -DUSE_LIBICONV=1 -DDL_MYSQL=1 -DMYSQL_LIB=libmysqlclient.so.18 -DDL_PGSQL=1 -DPGSQL_LIB=libpq.so.5 -DDATADIR=/var/data -DSPLIT_SYMBOLS=ON -DUSE_BISON=ON -DUSE_FLEX=ON -DUSE_SYSLOG=1 -DWITH_EXPAT=ON -DWITH_ICONV=ON -DWITH_MYSQL=ON -DWITH_ODBC=ON -DWITH_PGSQL=ON -DWITH_RE2=ON -DWITH_STEMMER=ON -DWITH_ZLIB=ON -DSYSCONFDIR=/etc/sphinxsearch
Host OS is Linux f355da8a9849 4.8.0-45-generic #48~16.04.1-Ubuntu SMP Fri Mar 24 12:46:56 UTC 2017 x86_64 GNU/Linux
Stack bottom = 0x7f6bbb611eaf, thread stack size = 0x100000
Trying manual backtrace:
Something wrong with thread stack, manual backtrace may be incorrect (fp=0x4)
Wrong stack limit or frame pointer, manual backtrace failed (fp=0x4, stack=0x7f6bbb610000, stacksize=0x100000)
Trying system backtrace:
[Wed Jan 17 10:39:26.168 2018] [7074] watchdog: main process 13219 killed dirtily with signal 11, will be restarted
[Wed Jan 17 10:39:26.168 2018] [7074] watchdog: main process 13264 forked ok
[Wed Jan 17 10:39:26.169 2018] [13264] listening on all interfaces, port=9313
[Wed Jan 17 10:39:26.170 2018] [13264] listening on all interfaces, port=9307
[Wed Jan 17 10:39:26.177 2018] [13264] binlog: replaying log /var/www/vhosts/elf925.com/sphinx/log/binlog.001
[Wed Jan 17 10:39:26.177 2018] [13264] binlog: replay stats: 0 rows in 0 commits; 0 updates, 0 reconfigure; 0 indexes
[Wed Jan 17 10:39:26.177 2018] [13264] binlog: finished replaying /var/www/vhosts/elf925.com/sphinx/log/binlog.001; 0.0 MB in 0.000 sec
[Wed Jan 17 10:39:26.177 2018] [13264] binlog: replaying log /var/www/vhosts/elf925.com/sphinx/log/binlog.002
[Wed Jan 17 10:39:26.177 2018] [13264] binlog: replay stats: 0 rows in 0 commits; 0 updates, 0 reconfigure; 0 indexes
[Wed Jan 17 10:39:26.177 2018] [13264] binlog: finished replaying /var/www/vhosts/elf925.com/sphinx/log/binlog.002; 0.0 MB in 0.000 sec
[Wed Jan 17 10:39:26.177 2018] [13264] binlog: replaying log /var/www/vhosts/elf925.com/sphinx/log/binlog.002
[Wed Jan 17 10:39:26.177 2018] [13264] binlog: replay stats: 0 rows in 0 commits; 0 updates, 0 reconfigure; 0 indexes
[Wed Jan 17 10:39:26.177 2018] [13264] binlog: finished replaying /var/www/vhosts/elf925.com/sphinx/log/binlog.002; 0.0 MB in 0.000 sec
[Wed Jan 17 10:39:26.177 2018] [13264] binlog: replaying log /var/www/vhosts/elf925.com/sphinx/log/binlog.003
[Wed Jan 17 10:39:26.177 2018] [13264] binlog: replay stats: 0 rows in 0 commits; 0 updates, 0 reconfigure; 0 indexes
[Wed Jan 17 10:39:26.177 2018] [13264] binlog: finished replaying /var/www/vhosts/elf925.com/sphinx/log/binlog.003; 0.0 MB in 0.000 sec
[Wed Jan 17 10:39:26.177 2018] [13264] binlog: replaying log /var/www/vhosts/elf925.com/sphinx/log/binlog.004
[Wed Jan 17 10:39:26.177 2018] [13264] binlog: replay stats: 0 rows in 0 commits; 0 updates, 0 reconfigure; 0 indexes
[Wed Jan 17 10:39:26.177 2018] [13264] binlog: finished replaying /var/www/vhosts/elf925.com/sphinx/log/binlog.004; 0.0 MB in 0.000 sec
[Wed Jan 17 10:39:26.177 2018] [13264] binlog: finished replaying total 5 in 0.000 sec
[Wed Jan 17 10:39:26.178 2018] [13302] prereading 4 indexes
[Wed Jan 17 10:39:26.178 2018] [13264] accepting connections
[Wed Jan 17 10:39:26.239 2018] [13302] prereaded 4 indexes in 0.062 sec
------- FATAL: CRASH DUMP -------
[Wed Jan 17 10:39:28.180 2018] [13264]

--- crashed SphinxAPI request dump ---
AAABHQAAAeMAAAAAAAAAAQAAAAAAAAAAAAABLAAAAAEAAAAHAAAAAQAAAA5kYXRlX2F2YWlsYWJsZQAAABMqR2Vt
IGpld2Vscnkgd29tZW4qAAAAAAAAAARtYWluAAAAAQAAAAAAAAAAAAAAAAAAAAAAAAAFAAAACHF1YW50
aXR5AAAAAQAAAAAAAAABAAAAAH/4nsAAAAAAAAAACnNvcnRfcHJpY2UAAAACAAAAAELIAAAAAAAAAAAA
BnN0YXR1cwAAAAAAAAABAAAAAAAAAAEAAAAAAAAADHN0b3JlX2ZpbHRlcgAAAAAAAAABAAAAAAAAAAAA
AAAAAAAAC2xhbmd1YWdlX2lkAAAAAAAAAAEAAAAAAAAAAQAAAAAAAAAAAAAAAAAAA+gAAAALQGdy
b3VwIGRlc2MAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAABwAAAARuYW1lAAAAAQAAAAtkZXNj
cmlwdGlvbgAAAAEAAAAFbW9kZWwAAAABAAAADGN1c3RvbV90aXRsZQAAAAEAAAADdGFnAAAAAQAAABBt
ZXRhX2Rlc2NyaXB0aW9uAAAAAQAAAAxtZXRhX2tleXdvcmQAAAABAAAAAAAAAAAAAAABKgAAAAAAAAAA
AAAAAAAAAAA=
--- request dump end ---
Sphinx 2.6.0 b84f229@171228 release
Handling signal 11
-------------- backtrace begins here ---------------
Program compiled with 4.7
Configured with flags: Configured by CMake with these definitions: -DCMAKE_BUILD_TYPE=RelWithDebInfo -DDISTR_BUILD=wheezy -DDL_UNIXODBC=1 -DUNIXODBC_LIB=libodbc.so.1 -DDL_EXPAT=1 -DEXPAT_LIB=libexpat.so.1 -DUSE_LIBICONV=1 -DDL_MYSQL=1 -DMYSQL_LIB=libmysqlclient.so.18 -DDL_PGSQL=1 -DPGSQL_LIB=libpq.so.5 -DDATADIR=/var/data -DSPLIT_SYMBOLS=ON -DUSE_BISON=ON -DUSE_FLEX=ON -DUSE_SYSLOG=1 -DWITH_EXPAT=ON -DWITH_ICONV=ON -DWITH_MYSQL=ON -DWITH_ODBC=ON -DWITH_PGSQL=ON -DWITH_RE2=ON -DWITH_STEMMER=ON -DWITH_ZLIB=ON -DSYSCONFDIR=/etc/sphinxsearch
Host OS is Linux f355da8a9849 4.8.0-45-generic #48~16.04.1-Ubuntu SMP Fri Mar 24 12:46:56 UTC 2017 x86_64 GNU/Linux
Stack bottom = 0x7f6bbadf1eaf, thread stack size = 0x100000
Trying manual backtrace:
Something wrong with thread stack, manual backtrace may be incorrect (fp=0x4)
Wrong stack limit or frame pointer, manual backtrace failed (fp=0x4, stack=0x7f6bbadf0000, stacksize=0x100000)
Trying system backtrace:
[Wed Jan 17 10:39:28.686 2018] [7074] watchdog: main process 13264 killed dirtily with signal 11, will be restarted
[Wed Jan 17 10:39:28.686 2018] [7074] watchdog: main process 13305 forked ok
[Wed Jan 17 10:39:28.687 2018] [13305] listening on all interfaces, port=9313
[Wed Jan 17 10:39:28.687 2018] [13305] listening on all interfaces, port=9307
[Wed Jan 17 10:39:28.695 2018] [13305] binlog: replaying log /var/www/vhosts/elf925.com/sphinx/log/binlog.001
[Wed Jan 17 10:39:28.695 2018] [13305] binlog: replay stats: 0 rows in 0 commits; 0 updates, 0 reconfigure; 0 indexes
[Wed Jan 17 10:39:28.695 2018] [13305] binlog: finished replaying /var/www/vhosts/elf925.com/sphinx/log/binlog.001; 0.0 MB in 0.000 sec
[Wed Jan 17 10:39:28.695 2018] [13305] binlog: replaying log /var/www/vhosts/elf925.com/sphinx/log/binlog.002
[Wed Jan 17 10:39:28.695 2018] [13305] binlog: replay stats: 0 rows in 0 commits; 0 updates, 0 reconfigure; 0 indexes
[Wed Jan 17 10:39:28.695 2018] [13305] binlog: finished replaying /var/www/vhosts/elf925.com/sphinx/log/binlog.002; 0.0 MB in 0.000 sec
[Wed Jan 17 10:39:28.695 2018] [13305] binlog: replaying log /var/www/vhosts/elf925.com/sphinx/log/binlog.002
[Wed Jan 17 10:39:28.695 2018] [13305] binlog: replay stats: 0 rows in 0 commits; 0 updates, 0 reconfigure; 0 indexes
[Wed Jan 17 10:39:28.695 2018] [13305] binlog: finished replaying /var/www/vhosts/elf925.com/sphinx/log/binlog.002; 0.0 MB in 0.000 sec
[Wed Jan 17 10:39:28.695 2018] [13305] binlog: replaying log /var/www/vhosts/elf925.com/sphinx/log/binlog.003
[Wed Jan 17 10:39:28.695 2018] [13305] binlog: replay stats: 0 rows in 0 commits; 0 updates, 0 reconfigure; 0 indexes
[Wed Jan 17 10:39:28.695 2018] [13305] binlog: finished replaying /var/www/vhosts/elf925.com/sphinx/log/binlog.003; 0.0 MB in 0.000 sec
[Wed Jan 17 10:39:28.695 2018] [13305] binlog: replaying log /var/www/vhosts/elf925.com/sphinx/log/binlog.004
[Wed Jan 17 10:39:28.695 2018] [13305] binlog: replay stats: 0 rows in 0 commits; 0 updates, 0 reconfigure; 0 indexes
[Wed Jan 17 10:39:28.695 2018] [13305] binlog: finished replaying /var/www/vhosts/elf925.com/sphinx/log/binlog.004; 0.0 MB in 0.000 sec
[Wed Jan 17 10:39:28.695 2018] [13305] binlog: replaying log /var/www/vhosts/elf925.com/sphinx/log/binlog.005
[Wed Jan 17 10:39:28.695 2018] [13305] binlog: replay stats: 0 rows in 0 commits; 0 updates, 0 reconfigure; 0 indexes
[Wed Jan 17 10:39:28.695 2018] [13305] binlog: finished replaying /var/www/vhosts/elf925.com/sphinx/log/binlog.005; 0.0 MB in 0.000 sec
[Wed Jan 17 10:39:28.695 2018] [13305] binlog: finished replaying total 6 in 0.000 sec
[Wed Jan 17 10:39:28.696 2018] [13343] prereading 4 indexes
[Wed Jan 17 10:39:28.696 2018] [13305] accepting connections
[Wed Jan 17 10:39:28.755 2018] [13343] prereaded 4 indexes in 0.060 sec
[Wed Jan 17 10:39:29.461 2018] [13305] caught SIGHUP (seamless=1, in_rotate=0, need_rotate=0)
[Wed Jan 17 10:39:29.496 2018] [13336] rotating index 'delta': started
[Wed Jan 17 10:39:29.545 2018] [13336] WARNING: binlog: failed to unlink /var/www/vhosts/elf925.com/sphinx/log/binlog.002: No such file or directory (remove it manually)
[Wed Jan 17 10:39:29.747 2018] [13336] rotating index 'delta': success
[Wed Jan 17 10:39:29.747 2018] [13336] rotating index: all indexes done
------- FATAL: CRASH DUMP -------
[Wed Jan 17 10:39:35.968 2018] [13305]

--- crashed SphinxAPI request dump ---
AAABHQAAAeMAAAAAAAAAAQAAAAAAAAJYAAABLAAAAAEAAAAHAAAAAQAAAA5kYXRlX2F2YWlsYWJsZQAAABMqR2Vt
IGpld2Vscnkgd29tZW4qAAAAAAAAAARtYWluAAAAAQAAAAAAAAAAAAAAAAAAAAAAAAAFAAAACHF1YW50
aXR5AAAAAQAAAAAAAAABAAAAAH/4nsAAAAAAAAAACnNvcnRfcHJpY2UAAAACAAAAAELIAAAAAAAAAAAA
BnN0YXR1cwAAAAAAAAABAAAAAAAAAAEAAAAAAAAADHN0b3JlX2ZpbHRlcgAAAAAAAAABAAAAAAAAAAAA
AAAAAAAAC2xhbmd1YWdlX2lkAAAAAAAAAAEAAAAAAAAAAQAAAAAAAAAAAAAAAAAAA+gAAAALQGdy
b3VwIGRlc2MAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAABwAAAARuYW1lAAAAAQAAAAtkZXNj
cmlwdGlvbgAAAAEAAAAFbW9kZWwAAAABAAAADGN1c3RvbV90aXRsZQAAAAEAAAADdGFnAAAAAQAAABBt
ZXRhX2Rlc2NyaXB0aW9uAAAAAQAAAAxtZXRhX2tleXdvcmQAAAABAAAAAAAAAAAAAAABKgAAAAAAAAAA
AAAAAAAAAAA=
--- request dump end ---
Sphinx 2.6.0 b84f229@171228 release
Handling signal 11
-------------- backtrace begins here ---------------
Program compiled with 4.7
Configured with flags: Configured by CMake with these definitions: -DCMAKE_BUILD_TYPE=RelWithDebInfo -DDISTR_BUILD=wheezy -DDL_UNIXODBC=1 -DUNIXODBC_LIB=libodbc.so.1 -DDL_EXPAT=1 -DEXPAT_LIB=libexpat.so.1 -DUSE_LIBICONV=1 -DDL_MYSQL=1 -DMYSQL_LIB=libmysqlclient.so.18 -DDL_PGSQL=1 -DPGSQL_LIB=libpq.so.5 -DDATADIR=/var/data -DSPLIT_SYMBOLS=ON -DUSE_BISON=ON -DUSE_FLEX=ON -DUSE_SYSLOG=1 -DWITH_EXPAT=ON -DWITH_ICONV=ON -DWITH_MYSQL=ON -DWITH_ODBC=ON -DWITH_PGSQL=ON -DWITH_RE2=ON -DWITH_STEMMER=ON -DWITH_ZLIB=ON -DSYSCONFDIR=/etc/sphinxsearch
Host OS is Linux f355da8a9849 4.8.0-45-generic #48~16.04.1-Ubuntu SMP Fri Mar 24 12:46:56 UTC 2017 x86_64 GNU/Linux
Stack bottom = 0x7f6bbb50deaf, thread stack size = 0x100000
Trying manual backtrace:
Something wrong with thread stack, manual backtrace may be incorrect (fp=0x4)
Wrong stack limit or frame pointer, manual backtrace failed (fp=0x4, stack=0x7f6bbb510000, stacksize=0x100000)
Trying system backtrace:
[Wed Jan 17 10:39:36.329 2018] [7074] watchdog: main process 13305 killed dirtily with signal 11, will be restarted
[Wed Jan 17 10:39:36.329 2018] [7074] watchdog: main process 13351 forked ok
[Wed Jan 17 10:39:36.330 2018] [13351] listening on all interfaces, port=9313
[Wed Jan 17 10:39:36.331 2018] [13351] listening on all interfaces, port=9307
[Wed Jan 17 10:39:36.339 2018] [13351] binlog: replaying log /var/www/vhosts/elf925.com/sphinx/log/binlog.001
[Wed Jan 17 10:39:36.339 2018] [13351] binlog: replay stats: 0 rows in 0 commits; 0 updates, 0 reconfigure; 0 indexes
[Wed Jan 17 10:39:36.339 2018] [13351] binlog: finished replaying /var/www/vhosts/elf925.com/sphinx/log/binlog.001; 0.0 MB in 0.000 sec
[Wed Jan 17 10:39:36.339 2018] [13351] binlog: finished replaying total 1 in 0.000 sec
[Wed Jan 17 10:39:36.339 2018] [13389] prereading 4 indexes
[Wed Jan 17 10:39:36.340 2018] [13351] accepting connections
[Wed Jan 17 10:39:36.400 2018] [13389] prereaded 4 indexes in 0.060 sec
[Wed Jan 17 10:40:00.924 2018] [13351] caught SIGHUP (seamless=1, in_rotate=0, need_rotate=0)
[Wed Jan 17 10:40:00.934 2018] [13382] rotating index 'delta': started
[Wed Jan 17 10:40:00.971 2018] [13382] rotating index 'delta': success
[Wed Jan 17 10:40:00.971 2018] [13382] rotating index: all indexes done
------- FATAL: CRASH DUMP -------
[Wed Jan 17 10:40:56.481 2018] [13351]

--- crashed SphinxAPI request dump ---
AAABHQAAAdwAAAAAAAAAAQAAAAAAAAAAAAAABQAAAAEAAAAHAAAAAQAAAApwcm9kdWN0X2lkAAAAECpyb3NlIGdv
bGQgcmluZyoAAAAAAAAABG1haW4AAAABAAAAAAAAAAAAAAAAAAAAAAAAAAUAAAAIcXVhbnRpdHkAAAAB
AAAAAAAAAAEAAAAAf/iewAAAAAAAAAAKc29ydF9wcmljZQAAAAIAAAAATv/xPgAAAAAAAAAGc3RhdHVz
AAAAAAAAAAEAAAAAAAAAAQAAAAAAAAAMc3RvcmVfZmlsdGVyAAAAAAAAAAEAAAAAAAAAAAAAAAAAAAAL
bGFuZ3VhZ2VfaWQAAAAAAAAAAQAAAAAAAAABAAAAAAAAAAAAAAAAAAAD6AAAAAtAZ3JvdXAgZGVz
YwAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAHAAAABG5hbWUAAAABAAAAC2Rlc2NyaXB0aW9u
AAAAAQAAAAVtb2RlbAAAAAEAAAAMY3VzdG9tX3RpdGxlAAAAAQAAAAN0YWcAAAABAAAAEG1ldGFfZGVz
Y3JpcHRpb24AAAABAAAADG1ldGFfa2V5d29yZAAAAAEAAAAAAAAAAAAAAAEqAAAAAAAAAAAAAAAAAAAAAA==
--- request dump end ---
Sphinx 2.6.0 b84f229@171228 release
Handling signal 11
-------------- backtrace begins here ---------------
Program compiled with 4.7
Configured with flags: Configured by CMake with these definitions: -DCMAKE_BUILD_TYPE=RelWithDebInfo -DDISTR_BUILD=wheezy -DDL_UNIXODBC=1 -DUNIXODBC_LIB=libodbc.so.1 -DDL_EXPAT=1 -DEXPAT_LIB=libexpat.so.1 -DUSE_LIBICONV=1 -DDL_MYSQL=1 -DMYSQL_LIB=libmysqlclient.so.18 -DDL_PGSQL=1 -DPGSQL_LIB=libpq.so.5 -DDATADIR=/var/data -DSPLIT_SYMBOLS=ON -DUSE_BISON=ON -DUSE_FLEX=ON -DUSE_SYSLOG=1 -DWITH_EXPAT=ON -DWITH_ICONV=ON -DWITH_MYSQL=ON -DWITH_ODBC=ON -DWITH_PGSQL=ON -DWITH_RE2=ON -DWITH_STEMMER=ON -DWITH_ZLIB=ON -DSYSCONFDIR=/etc/sphinxsearch
Host OS is Linux f355da8a9849 4.8.0-45-generic #48~16.04.1-Ubuntu SMP Fri Mar 24 12:46:56 UTC 2017 x86_64 GNU/Linux
Stack bottom = 0x7f6bba9e1eaf, thread stack size = 0x100000
Trying manual backtrace:
Something wrong with thread stack, manual backtrace may be incorrect (fp=0x4)
Wrong stack limit or frame pointer, manual backtrace failed (fp=0x4, stack=0x7f6bba9e0000, stacksize=0x100000)
Trying system backtrace:
[Wed Jan 17 10:40:56.511 2018] [7074] watchdog: main process 13351 killed dirtily with signal 11, will be restarted
[Wed Jan 17 10:40:56.512 2018] [7074] watchdog: main process 13544 forked ok
[Wed Jan 17 10:40:56.513 2018] [13544] listening on all interfaces, port=9313
[Wed Jan 17 10:40:56.513 2018] [13544] listening on all interfaces, port=9307
[Wed Jan 17 10:40:56.521 2018] [13544] binlog: replaying log /var/www/vhosts/elf925.com/sphinx/log/binlog.001
[Wed Jan 17 10:40:56.521 2018] [13544] binlog: replay stats: 0 rows in 0 commits; 0 updates, 0 reconfigure; 0 indexes
[Wed Jan 17 10:40:56.521 2018] [13544] binlog: finished replaying /var/www/vhosts/elf925.com/sphinx/log/binlog.001; 0.0 MB in 0.000 sec
[Wed Jan 17 10:40:56.521 2018] [13544] binlog: finished replaying total 1 in 0.000 sec
[Wed Jan 17 10:40:56.522 2018] [13582] prereading 4 indexes
[Wed Jan 17 10:40:56.522 2018] [13544] accepting connections
------- FATAL: CRASH DUMP -------
[Wed Jan 17 10:40:56.522 2018] [13544]

--- crashed SphinxAPI request dump ---
AAABHQAAAdwAAAAAAAAAAQAAAAAAAAAAAAAABQAAAAEAAAAHAAAAAQAAAApwcm9kdWN0X2lkAAAAECpyb3NlIGdv
bGQgcmluZyoAAAAAAAAABG1haW4AAAABAAAAAAAAAAAAAAAAAAAAAAAAAAUAAAAIcXVhbnRpdHkAAAAB
AAAAAAAAAAEAAAAAf/iewAAAAAAAAAAKc29ydF9wcmljZQAAAAIAAAAATv/xPgAAAAAAAAAGc3RhdHVz
AAAAAAAAAAEAAAAAAAAAAQAAAAAAAAAMc3RvcmVfZmlsdGVyAAAAAAAAAAEAAAAAAAAAAAAAAAAAAAAL
bGFuZ3VhZ2VfaWQAAAAAAAAAAQAAAAAAAAABAAAAAAAAAAAAAAAAAAAD6AAAAAtAZ3JvdXAgZGVz
YwAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAHAAAABG5hbWUAAAABAAAAC2Rlc2NyaXB0aW9u
AAAAAQAAAAVtb2RlbAAAAAEAAAAMY3VzdG9tX3RpdGxlAAAAAQAAAAN0YWcAAAABAAAAEG1ldGFfZGVz
Y3JpcHRpb24AAAABAAAADG1ldGFfa2V5d29yZAAAAAEAAAAAAAAAAAAAAAEqAAAAAAAAAAAAAAAAAAAAAA==
--- request dump end ---
Sphinx 2.6.0 b84f229@171228 release
Handling signal 11
-------------- backtrace begins here ---------------
Program compiled with 4.7
Configured with flags: Configured by CMake with these definitions: -DCMAKE_BUILD_TYPE=RelWithDebInfo -DDISTR_BUILD=wheezy -DDL_UNIXODBC=1 -DUNIXODBC_LIB=libodbc.so.1 -DDL_EXPAT=1 -DEXPAT_LIB=libexpat.so.1 -DUSE_LIBICONV=1 -DDL_MYSQL=1 -DMYSQL_LIB=libmysqlclient.so.18 -DDL_PGSQL=1 -DPGSQL_LIB=libpq.so.5 -DDATADIR=/var/data -DSPLIT_SYMBOLS=ON -DUSE_BISON=ON -DUSE_FLEX=ON -DUSE_SYSLOG=1 -DWITH_EXPAT=ON -DWITH_ICONV=ON -DWITH_MYSQL=ON -DWITH_ODBC=ON -DWITH_PGSQL=ON -DWITH_RE2=ON -DWITH_STEMMER=ON -DWITH_ZLIB=ON -DSYSCONFDIR=/etc/sphinxsearch
Host OS is Linux f355da8a9849 4.8.0-45-generic #48~16.04.1-Ubuntu SMP Fri Mar 24 12:46:56 UTC 2017 x86_64 GNU/Linux
Stack bottom = 0x7f6bbb611eaf, thread stack size = 0x100000
Trying manual backtrace:
Something wrong with thread stack, manual backtrace may be incorrect (fp=0x4)
Wrong stack limit or frame pointer, manual backtrace failed (fp=0x4, stack=0x7f6bbb610000, stacksize=0x100000)
Trying system backtrace:
[Wed Jan 17 10:40:56.559 2018] [7074] watchdog: main process 13544 killed dirtily with signal 11, will be restarted
[Wed Jan 17 10:40:56.559 2018] [7074] watchdog: main process 13584 forked ok
[Wed Jan 17 10:40:56.560 2018] [13584] listening on all interfaces, port=9313
[Wed Jan 17 10:40:56.561 2018] [13584] listening on all interfaces, port=9307
[Wed Jan 17 10:40:56.569 2018] [13584] binlog: replaying log /var/www/vhosts/elf925.com/sphinx/log/binlog.001
[Wed Jan 17 10:40:56.569 2018] [13584] binlog: replay stats: 0 rows in 0 commits; 0 updates, 0 reconfigure; 0 indexes
[Wed Jan 17 10:40:56.569 2018] [13584] binlog: finished replaying /var/www/vhosts/elf925.com/sphinx/log/binlog.001; 0.0 MB in 0.000 sec
[Wed Jan 17 10:40:56.569 2018] [13584] binlog: replaying log /var/www/vhosts/elf925.com/sphinx/log/binlog.002
[Wed Jan 17 10:40:56.569 2018] [13584] WARNING: binlog: empty binlog /var/www/vhosts/elf925.com/sphinx/log/binlog.002 detected, skipping
[Wed Jan 17 10:40:56.569 2018] [13584] binlog: finished replaying total 2 in 0.000 sec
[Wed Jan 17 10:40:56.569 2018] [13622] prereading 4 indexes
[Wed Jan 17 10:40:56.569 2018] [13584] accepting connections
[Wed Jan 17 10:40:56.632 2018] [13622] prereaded 4 indexes in 0.062 sec
------- FATAL: CRASH DUMP -------
[Wed Jan 17 10:40:57.070 2018] [13584]

--- crashed SphinxAPI request dump ---
AAABHQAAAeAAAAAAAAAAAQAAAAAAAAAAAAAAMAAAAAEAAAAHAAAAAQAAAA5kYXRlX2F2YWlsYWJsZQAAABAqcm9z
ZSBnb2xkIHJpbmcqAAAAAAAAAARtYWluAAAAAQAAAAAAAAAAAAAAAAAAAAAAAAAFAAAACHF1YW50aXR5
AAAAAQAAAAAAAAABAAAAAH/4nsAAAAAAAAAACnNvcnRfcHJpY2UAAAACAAAAAELIAAAAAAAAAAAABnN0
YXR1cwAAAAAAAAABAAAAAAAAAAEAAAAAAAAADHN0b3JlX2ZpbHRlcgAAAAAAAAABAAAAAAAAAAAAAAAA
AAAAC2xhbmd1YWdlX2lkAAAAAAAAAAEAAAAAAAAAAQAAAAAAAAAAAAAAAAAAA+gAAAALQGdyb3Vw
IGRlc2MAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAABwAAAARuYW1lAAAAAQAAAAtkZXNjcmlw
dGlvbgAAAAEAAAAFbW9kZWwAAAABAAAADGN1c3RvbV90aXRsZQAAAAEAAAADdGFnAAAAAQAAABBtZXRh
X2Rlc2NyaXB0aW9uAAAAAQAAAAxtZXRhX2tleXdvcmQAAAABAAAAAAAAAAAAAAABKgAAAAAAAAAAAAAA
AAAAAAA=
--- request dump end ---
Sphinx 2.6.0 b84f229@171228 release
Handling signal 11
-------------- backtrace begins here ---------------
Program compiled with 4.7
Configured with flags: Configured by CMake with these definitions: -DCMAKE_BUILD_TYPE=RelWithDebInfo -DDISTR_BUILD=wheezy -DDL_UNIXODBC=1 -DUNIXODBC_LIB=libodbc.so.1 -DDL_EXPAT=1 -DEXPAT_LIB=libexpat.so.1 -DUSE_LIBICONV=1 -DDL_MYSQL=1 -DMYSQL_LIB=libmysqlclient.so.18 -DDL_PGSQL=1 -DPGSQL_LIB=libpq.so.5 -DDATADIR=/var/data -DSPLIT_SYMBOLS=ON -DUSE_BISON=ON -DUSE_FLEX=ON -DUSE_SYSLOG=1 -DWITH_EXPAT=ON -DWITH_ICONV=ON -DWITH_MYSQL=ON -DWITH_ODBC=ON -DWITH_PGSQL=ON -DWITH_RE2=ON -DWITH_STEMMER=ON -DWITH_ZLIB=ON -DSYSCONFDIR=/etc/sphinxsearch
Host OS is Linux f355da8a9849 4.8.0-45-generic #48~16.04.1-Ubuntu SMP Fri Mar 24 12:46:56 UTC 2017 x86_64 GNU/Linux
Stack bottom = 0x7f6bbb611eaf, thread stack size = 0x100000
Trying manual backtrace:
Something wrong with thread stack, manual backtrace may be incorrect (fp=0x4)
Wrong stack limit or frame pointer, manual backtrace failed (fp=0x4, stack=0x7f6bbb610000, stacksize=0x100000)
Trying system backtrace:
[Wed Jan 17 10:40:57.252 2018] [7074] watchdog: main process 13584 killed dirtily with signal 11, will be restarted
[Wed Jan 17 10:40:57.253 2018] [7074] watchdog: main process 13624 forked ok
[Wed Jan 17 10:40:57.254 2018] [13624] listening on all interfaces, port=9313
[Wed Jan 17 10:40:57.254 2018] [13624] listening on all interfaces, port=9307
[Wed Jan 17 10:40:57.261 2018] [13624] binlog: replaying log /var/www/vhosts/elf925.com/sphinx/log/binlog.001
[Wed Jan 17 10:40:57.261 2018] [13624] binlog: replay stats: 0 rows in 0 commits; 0 updates, 0 reconfigure; 0 indexes
[Wed Jan 17 10:40:57.261 2018] [13624] binlog: finished replaying /var/www/vhosts/elf925.com/sphinx/log/binlog.001; 0.0 MB in 0.000 sec
[Wed Jan 17 10:40:57.261 2018] [13624] binlog: replaying log /var/www/vhosts/elf925.com/sphinx/log/binlog.002
[Wed Jan 17 10:40:57.261 2018] [13624] WARNING: binlog: empty binlog /var/www/vhosts/elf925.com/sphinx/log/binlog.002 detected, skipping
[Wed Jan 17 10:40:57.261 2018] [13624] binlog: replaying log /var/www/vhosts/elf925.com/sphinx/log/binlog.002
[Wed Jan 17 10:40:57.261 2018] [13624] WARNING: binlog: empty binlog /var/www/vhosts/elf925.com/sphinx/log/binlog.002 detected, skipping
[Wed Jan 17 10:40:57.261 2018] [13624] binlog: finished replaying total 3 in 0.000 sec
[Wed Jan 17 10:40:57.262 2018] [13662] prereading 4 indexes
[Wed Jan 17 10:40:57.262 2018] [13624] accepting connections
[Wed Jan 17 10:40:57.325 2018] [13662] prereaded 4 indexes in 0.063 sec
[Wed Jan 17 10:41:14.741 2018] [13624] caught SIGHUP (seamless=1, in_rotate=0, need_rotate=0)
[Wed Jan 17 10:41:14.743 2018] [13655] rotating index 'delta': started
[Wed Jan 17 10:41:14.767 2018] [13655] WARNING: binlog: failed to unlink /var/www/vhosts/elf925.com/sphinx/log/binlog.002: No such file or directory (remove it manually)
[Wed Jan 17 10:41:14.782 2018] [13655] last message repeated 1 times
[Wed Jan 17 10:41:14.782 2018] [13655] rotating index 'delta': success
[Wed Jan 17 10:41:14.782 2018] [13655] rotating index: all indexes done
------- FATAL: CRASH DUMP -------
[Wed Jan 17 10:41:41.769 2018] [13624]

--- crashed SphinxAPI request dump ---
AAABHQAAAdEAAAAAAAAAAQAAAAAAAAAAAAAABQAAAAEAAAAHAAAAAQAAAApwcm9kdWN0X2lkAAAABSp3b3cqAAAA
AAAAAARtYWluAAAAAQAAAAAAAAAAAAAAAAAAAAAAAAAFAAAACHF1YW50aXR5AAAAAQAAAAAAAAABAAAA
AH/4nsAAAAAAAAAACnNvcnRfcHJpY2UAAAACAAAAAE7/8T4AAAAAAAAABnN0YXR1cwAAAAAAAAABAAAA
AAAAAAEAAAAAAAAADHN0b3JlX2ZpbHRlcgAAAAAAAAABAAAAAAAAAAAAAAAAAAAAC2xhbmd1YWdlX2lk
AAAAAAAAAAEAAAAAAAAAAQAAAAAAAAAAAAAAAAAAA+gAAAALQGdyb3VwIGRlc2MAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAABwAAAARuYW1lAAAAAQAAAAtkZXNjcmlwdGlvbgAAAAEAAAAFbW9k
ZWwAAAABAAAADGN1c3RvbV90aXRsZQAAAAEAAAADdGFnAAAAAQAAABBtZXRhX2Rlc2NyaXB0aW9uAAAA
AQAAAAxtZXRhX2tleXdvcmQAAAABAAAAAAAAAAAAAAABKgAAAAAAAAAAAAAAAAAAAAA=
--- request dump end ---
Sphinx 2.6.0 b84f229@171228 release
Handling signal 11
-------------- backtrace begins here ---------------
Program compiled with 4.7
Configured with flags: Configured by CMake with these definitions: -DCMAKE_BUILD_TYPE=RelWithDebInfo -DDISTR_BUILD=wheezy -DDL_UNIXODBC=1 -DUNIXODBC_LIB=libodbc.so.1 -DDL_EXPAT=1 -DEXPAT_LIB=libexpat.so.1 -DUSE_LIBICONV=1 -DDL_MYSQL=1 -DMYSQL_LIB=libmysqlclient.so.18 -DDL_PGSQL=1 -DPGSQL_LIB=libpq.so.5 -DDATADIR=/var/data -DSPLIT_SYMBOLS=ON -DUSE_BISON=ON -DUSE_FLEX=ON -DUSE_SYSLOG=1 -DWITH_EXPAT=ON -DWITH_ICONV=ON -DWITH_MYSQL=ON -DWITH_ODBC=ON -DWITH_PGSQL=ON -DWITH_RE2=ON -DWITH_STEMMER=ON -DWITH_ZLIB=ON -DSYSCONFDIR=/etc/sphinxsearch
Host OS is Linux f355da8a9849 4.8.0-45-generic #48~16.04.1-Ubuntu SMP Fri Mar 24 12:46:56 UTC 2017 x86_64 GNU/Linux
Stack bottom = 0x7f6bbb715eaf, thread stack size = 0x100000
Trying manual backtrace:
Something wrong with thread stack, manual backtrace may be incorrect (fp=0x4)
Wrong stack limit or frame pointer, manual backtrace failed (fp=0x4, stack=0x7f6bbb720000, stacksize=0x100000)
Trying system backtrace:
[Wed Jan 17 10:41:42.261 2018] [7074] watchdog: main process 13624 killed dirtily with signal 11, will be restarted
[Wed Jan 17 10:41:42.262 2018] [7074] watchdog: main process 13710 forked ok
[Wed Jan 17 10:41:42.263 2018] [13710] listening on all interfaces, port=9313
[Wed Jan 17 10:41:42.263 2018] [13710] listening on all interfaces, port=9307
[Wed Jan 17 10:41:42.271 2018] [13710] binlog: replaying log /var/www/vhosts/elf925.com/sphinx/log/binlog.001
[Wed Jan 17 10:41:42.271 2018] [13710] binlog: replay stats: 0 rows in 0 commits; 0 updates, 0 reconfigure; 0 indexes
[Wed Jan 17 10:41:42.271 2018] [13710] binlog: finished replaying /var/www/vhosts/elf925.com/sphinx/log/binlog.001; 0.0 MB in 0.000 sec
[Wed Jan 17 10:41:42.271 2018] [13710] binlog: finished replaying total 1 in 0.000 sec
[Wed Jan 17 10:41:42.271 2018] [13748] prereading 4 indexes
[Wed Jan 17 10:41:42.272 2018] [13710] accepting connections
[Wed Jan 17 10:41:42.331 2018] [13748] prereaded 4 indexes in 0.059 sec
------- FATAL: CRASH DUMP -------
[Wed Jan 17 10:41:43.272 2018] [13710]

--- crashed SphinxAPI request dump ---
AAABHQAAAdUAAAAAAAAAAQAAAAAAAAAAAAAAMAAAAAEAAAAHAAAAAQAAAA5kYXRlX2F2YWlsYWJsZQAAAAUqd293
KgAAAAAAAAAEbWFpbgAAAAEAAAAAAAAAAAAAAAAAAAAAAAAABQAAAAhxdWFudGl0eQAAAAEAAAAAAAAA
AQAAAAB/+J7AAAAAAAAAAApzb3J0X3ByaWNlAAAAAgAAAABCyAAAAAAAAAAAAAZzdGF0dXMAAAAAAAAA
AQAAAAAAAAABAAAAAAAAAAxzdG9yZV9maWx0ZXIAAAAAAAAAAQAAAAAAAAAAAAAAAAAAAAtsYW5ndWFn
ZV9pZAAAAAAAAAABAAAAAAAAAAEAAAAAAAAAAAAAAAAAAAPoAAAAC0Bncm91cCBkZXNjAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAcAAAAEbmFtZQAAAAEAAAALZGVzY3JpcHRpb24AAAABAAAA
BW1vZGVsAAAAAQAAAAxjdXN0b21fdGl0bGUAAAABAAAAA3RhZwAAAAEAAAAQbWV0YV9kZXNjcmlwdGlv
bgAAAAEAAAAMbWV0YV9rZXl3b3JkAAAAAQAAAAAAAAAAAAAAASoAAAAAAAAAAAAAAAAAAAAA
--- request dump end ---
Sphinx 2.6.0 b84f229@171228 release
Handling signal 11
-------------- backtrace begins here ---------------
Program compiled with 4.7
Configured with flags: Configured by CMake with these definitions: -DCMAKE_BUILD_TYPE=RelWithDebInfo -DDISTR_BUILD=wheezy -DDL_UNIXODBC=1 -DUNIXODBC_LIB=libodbc.so.1 -DDL_EXPAT=1 -DEXPAT_LIB=libexpat.so.1 -DUSE_LIBICONV=1 -DDL_MYSQL=1 -DMYSQL_LIB=libmysqlclient.so.18 -DDL_PGSQL=1 -DPGSQL_LIB=libpq.so.5 -DDATADIR=/var/data -DSPLIT_SYMBOLS=ON -DUSE_BISON=ON -DUSE_FLEX=ON -DUSE_SYSLOG=1 -DWITH_EXPAT=ON -DWITH_ICONV=ON -DWITH_MYSQL=ON -DWITH_ODBC=ON -DWITH_PGSQL=ON -DWITH_RE2=ON -DWITH_STEMMER=ON -DWITH_ZLIB=ON -DSYSCONFDIR=/etc/sphinxsearch
Host OS is Linux f355da8a9849 4.8.0-45-generic #48~16.04.1-Ubuntu SMP Fri Mar 24 12:46:56 UTC 2017 x86_64 GNU/Linux
Stack bottom = 0x7f6bbb611eaf, thread stack size = 0x100000
Trying manual backtrace:
Something wrong with thread stack, manual backtrace may be incorrect (fp=0x4)
Wrong stack limit or frame pointer, manual backtrace failed (fp=0x4, stack=0x7f6bbb610000, stacksize=0x100000)
Trying system backtrace:
[Wed Jan 17 10:41:43.697 2018] [7074] watchdog: main process 13710 killed dirtily with signal 11, will be restarted
[Wed Jan 17 10:41:43.698 2018] [7074] watchdog: main process 13751 forked ok
[Wed Jan 17 10:41:43.699 2018] [13751] listening on all interfaces, port=9313
[Wed Jan 17 10:41:43.699 2018] [13751] listening on all interfaces, port=9307
[Wed Jan 17 10:41:43.706 2018] [13751] binlog: replaying log /var/www/vhosts/elf925.com/sphinx/log/binlog.001
[Wed Jan 17 10:41:43.706 2018] [13751] binlog: replay stats: 0 rows in 0 commits; 0 updates, 0 reconfigure; 0 indexes
[Wed Jan 17 10:41:43.707 2018] [13751] binlog: finished replaying /var/www/vhosts/elf925.com/sphinx/log/binlog.001; 0.0 MB in 0.000 sec
[Wed Jan 17 10:41:43.707 2018] [13751] binlog: replaying log /var/www/vhosts/elf925.com/sphinx/log/binlog.002
[Wed Jan 17 10:41:43.707 2018] [13751] binlog: replay stats: 0 rows in 0 commits; 0 updates, 0 reconfigure; 0 indexes
[Wed Jan 17 10:41:43.707 2018] [13751] binlog: finished replaying /var/www/vhosts/elf925.com/sphinx/log/binlog.002; 0.0 MB in 0.000 sec
[Wed Jan 17 10:41:43.707 2018] [13751] binlog: finished replaying total 2 in 0.000 sec
[Wed Jan 17 10:41:43.707 2018] [13789] prereading 4 indexes
[Wed Jan 17 10:41:43.707 2018] [13751] accepting connections
[Wed Jan 17 10:41:43.768 2018] [13789] prereaded 4 indexes in 0.060 sec
[Wed Jan 17 10:41:45.829 2018] [13751] caught SIGHUP (seamless=1, in_rotate=0, need_rotate=0)
[Wed Jan 17 10:41:45.860 2018] [13782] rotating index 'delta': started
[Wed Jan 17 10:41:45.891 2018] [13782] rotating index 'delta': success
[Wed Jan 17 10:41:45.891 2018] [13782] rotating index: all indexes done
------- FATAL: CRASH DUMP -------
[Wed Jan 17 10:42:08.853 2018] [13751]

--- crashed SphinxAPI request dump ---
AAABHQAAAdYAAAAAAAAAAQAAAAAAAAAAAAAAMAAAAAEAAAAHAAAAAQAAAA5kYXRlX2F2YWlsYWJsZQAAAAYqcm9z
ZSoAAAAAAAAABG1haW4AAAABAAAAAAAAAAAAAAAAAAAAAAAAAAUAAAAIcXVhbnRpdHkAAAABAAAAAAAA
AAEAAAAAf/iewAAAAAAAAAAKc29ydF9wcmljZQAAAAIAAAAAQsgAAAAAAAAAAAAGc3RhdHVzAAAAAAAA
AAEAAAAAAAAAAQAAAAAAAAAMc3RvcmVfZmlsdGVyAAAAAAAAAAEAAAAAAAAAAAAAAAAAAAALbGFuZ3Vh
Z2VfaWQAAAAAAAAAAQAAAAAAAAABAAAAAAAAAAAAAAAAAAAD6AAAAAtAZ3JvdXAgZGVzYwAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAHAAAABG5hbWUAAAABAAAAC2Rlc2NyaXB0aW9uAAAAAQAA
AAVtb2RlbAAAAAEAAAAMY3VzdG9tX3RpdGxlAAAAAQAAAAN0YWcAAAABAAAAEG1ldGFfZGVzY3JpcHRp
b24AAAABAAAADG1ldGFfa2V5d29yZAAAAAEAAAAAAAAAAAAAAAEqAAAAAAAAAAAAAAAAAAAAAA==
--- request dump end ---
Sphinx 2.6.0 b84f229@171228 release
Handling signal 11
-------------- backtrace begins here ---------------
Program compiled with 4.7
Configured with flags: Configured by CMake with these definitions: -DCMAKE_BUILD_TYPE=RelWithDebInfo -DDISTR_BUILD=wheezy -DDL_UNIXODBC=1 -DUNIXODBC_LIB=libodbc.so.1 -DDL_EXPAT=1 -DEXPAT_LIB=libexpat.so.1 -DUSE_LIBICONV=1 -DDL_MYSQL=1 -DMYSQL_LIB=libmysqlclient.so.18 -DDL_PGSQL=1 -DPGSQL_LIB=libpq.so.5 -DDATADIR=/var/data -DSPLIT_SYMBOLS=ON -DUSE_BISON=ON -DUSE_FLEX=ON -DUSE_SYSLOG=1 -DWITH_EXPAT=ON -DWITH_ICONV=ON -DWITH_MYSQL=ON -DWITH_ODBC=ON -DWITH_PGSQL=ON -DWITH_RE2=ON -DWITH_STEMMER=ON -DWITH_ZLIB=ON -DSYSCONFDIR=/etc/sphinxsearch
Host OS is Linux f355da8a9849 4.8.0-45-generic #48~16.04.1-Ubuntu SMP Fri Mar 24 12:46:56 UTC 2017 x86_64 GNU/Linux
Stack bottom = 0x7f6bbb50deaf, thread stack size = 0x100000
Trying manual backtrace:
Something wrong with thread stack, manual backtrace may be incorrect (fp=0x4)
Wrong stack limit or frame pointer, manual backtrace failed (fp=0x4, stack=0x7f6bbb510000, stacksize=0x100000)
Trying system backtrace:
[Wed Jan 17 10:42:08.942 2018] [7074] watchdog: main process 13751 killed dirtily with signal 11, will be restarted
[Wed Jan 17 10:42:08.942 2018] [7074] watchdog: main process 13871 forked ok
[Wed Jan 17 10:42:08.944 2018] [13871] listening on all interfaces, port=9313
[Wed Jan 17 10:42:08.944 2018] [13871] listening on all interfaces, port=9307
[Wed Jan 17 10:42:08.951 2018] [13871] binlog: replaying log /var/www/vhosts/elf925.com/sphinx/log/binlog.001
[Wed Jan 17 10:42:08.951 2018] [13871] binlog: replay stats: 0 rows in 0 commits; 0 updates, 0 reconfigure; 0 indexes
[Wed Jan 17 10:42:08.951 2018] [13871] binlog: finished replaying /var/www/vhosts/elf925.com/sphinx/log/binlog.001; 0.0 MB in 0.000 sec
[Wed Jan 17 10:42:08.951 2018] [13871] binlog: finished replaying total 1 in 0.000 sec
[Wed Jan 17 10:42:08.952 2018] [13871] accepting connections
[Wed Jan 17 10:42:08.956 2018] [13909] prereading 4 indexes
[Wed Jan 17 10:42:09.036 2018] [13909] prereaded 4 indexes in 0.079 sec
------- FATAL: CRASH DUMP -------
[Wed Jan 17 10:42:11.956 2018] [13871]

--- crashed SphinxAPI request dump ---
AAABHQAAAdIAAAAAAAAAAQAAAAAAAAAAAAAABQAAAAEAAAAHAAAAAQAAAApwcm9kdWN0X2lkAAAABipyb3NlKgAA
AAAAAAAEbWFpbgAAAAEAAAAAAAAAAAAAAAAAAAAAAAAABQAAAAhxdWFudGl0eQAAAAEAAAAAAAAAAQAA
AAB/+J7AAAAAAAAAAApzb3J0X3ByaWNlAAAAAgAAAABO//E+AAAAAAAAAAZzdGF0dXMAAAAAAAAAAQAA
AAAAAAABAAAAAAAAAAxzdG9yZV9maWx0ZXIAAAAAAAAAAQAAAAAAAAAAAAAAAAAAAAtsYW5ndWFnZV9p
ZAAAAAAAAAABAAAAAAAAAAEAAAAAAAAAAAAAAAAAAAPoAAAAC0Bncm91cCBkZXNjAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAcAAAAEbmFtZQAAAAEAAAALZGVzY3JpcHRpb24AAAABAAAABW1v
ZGVsAAAAAQAAAAxjdXN0b21fdGl0bGUAAAABAAAAA3RhZwAAAAEAAAAQbWV0YV9kZXNjcmlwdGlvbgAA
AAEAAAAMbWV0YV9rZXl3b3JkAAAAAQAAAAAAAAAAAAAAASoAAAAAAAAAAAAAAAAAAAAA
--- request dump end ---
Sphinx 2.6.0 b84f229@171228 release
Handling signal 11
-------------- backtrace begins here ---------------
Program compiled with 4.7
Configured with flags: Configured by CMake with these definitions: -DCMAKE_BUILD_TYPE=RelWithDebInfo -DDISTR_BUILD=wheezy -DDL_UNIXODBC=1 -DUNIXODBC_LIB=libodbc.so.1 -DDL_EXPAT=1 -DEXPAT_LIB=libexpat.so.1 -DUSE_LIBICONV=1 -DDL_MYSQL=1 -DMYSQL_LIB=libmysqlclient.so.18 -DDL_PGSQL=1 -DPGSQL_LIB=libpq.so.5 -DDATADIR=/var/data -DSPLIT_SYMBOLS=ON -DUSE_BISON=ON -DUSE_FLEX=ON -DUSE_SYSLOG=1 -DWITH_EXPAT=ON -DWITH_ICONV=ON -DWITH_MYSQL=ON -DWITH_ODBC=ON -DWITH_PGSQL=ON -DWITH_RE2=ON -DWITH_STEMMER=ON -DWITH_ZLIB=ON -DSYSCONFDIR=/etc/sphinxsearch
Host OS is Linux f355da8a9849 4.8.0-45-generic #48~16.04.1-Ubuntu SMP Fri Mar 24 12:46:56 UTC 2017 x86_64 GNU/Linux
Stack bottom = 0x7f6bba4cdeaf, thread stack size = 0x100000
Trying manual backtrace:
Something wrong with thread stack, manual backtrace may be incorrect (fp=0x4)
Wrong stack limit or frame pointer, manual backtrace failed (fp=0x4, stack=0x7f6bba4d0000, stacksize=0x100000)
Trying system backtrace:
[Wed Jan 17 10:42:12.150 2018] [7074] watchdog: main process 13871 killed dirtily with signal 11, will be restarted
[Wed Jan 17 10:42:12.150 2018] [7074] watchdog: main process 13916 forked ok
[Wed Jan 17 10:42:12.151 2018] [13916] listening on all interfaces, port=9313
[Wed Jan 17 10:42:12.151 2018] [13916] listening on all interfaces, port=9307
[Wed Jan 17 10:42:12.159 2018] [13916] binlog: replaying log /var/www/vhosts/elf925.com/sphinx/log/binlog.001
[Wed Jan 17 10:42:12.159 2018] [13916] binlog: replay stats: 0 rows in 0 commits; 0 updates, 0 reconfigure; 0 indexes
[Wed Jan 17 10:42:12.159 2018] [13916] binlog: finished replaying /var/www/vhosts/elf925.com/sphinx/log/binlog.001; 0.0 MB in 0.000 sec
[Wed Jan 17 10:42:12.159 2018] [13916] binlog: replaying log /var/www/vhosts/elf925.com/sphinx/log/binlog.002
[Wed Jan 17 10:42:12.159 2018] [13916] binlog: replay stats: 0 rows in 0 commits; 0 updates, 0 reconfigure; 0 indexes
[Wed Jan 17 10:42:12.159 2018] [13916] binlog: finished replaying /var/www/vhosts/elf925.com/sphinx/log/binlog.002; 0.0 MB in 0.000 sec
[Wed Jan 17 10:42:12.159 2018] [13916] binlog: finished replaying total 2 in 0.000 sec
[Wed Jan 17 10:42:12.160 2018] [13954] prereading 4 indexes
[Wed Jan 17 10:42:12.160 2018] [13916] accepting connections
[Wed Jan 17 10:42:12.221 2018] [13954] prereaded 4 indexes in 0.061 sec
[Wed Jan 17 10:42:19.129 2018] [13916] caught SIGHUP (seamless=1, in_rotate=0, need_rotate=0)
[Wed Jan 17 10:42:19.172 2018] [13947] rotating index 'delta': started
[Wed Jan 17 10:42:19.204 2018] [13947] rotating index 'delta': success
[Wed Jan 17 10:42:19.204 2018] [13947] rotating index: all indexes done
[Wed Jan 17 10:42:51.855 2018] [13916] caught SIGHUP (seamless=1, in_rotate=0, need_rotate=0)
[Wed Jan 17 10:42:51.863 2018] [13947] rotating index 'delta': started
[Wed Jan 17 10:42:51.905 2018] [13947] rotating index 'delta': success
[Wed Jan 17 10:42:51.932 2018] [13947] rotating index: all indexes done

Crash Sphinx 2.4.1 (Manticore)

Have crash and strange log from manticore. I din't find CRASH DUMP END in log.

------- FATAL: CRASH DUMP -------
[Sun Nov 12 09:31:16.536 2017] [27499]

--- crashed SphinxQL request dump ---
SELECT * FROM section_2020 WHERE id in (15893587) LIMIT 20000 OPTION max_matches=20000
--- request dump end ---
Sphinx 2.4.1 3b31a97@171017 id64-release
Handling signal 11
-------------- backtrace begins here ---------------
Program compiled with 4.8.5
Configured with flags: Configured by CMake with these definitions: -DCMAKE_BUILD_TYPE=RelWithDebInfo -DDL_UNIXODBC=1 -DUNIXODBC_LIB=libodbc.so.2 -DDL_EXPAT=1 -DEXPAT_LIB=libexpat.so.1 -DDL_MYSQL=1 -DMYSQL_LIB=libmysqlclient.so.18 -DMYSQL_CONFIG_EXECUTABLE=/bin/mysql_config -DDL_PGSQL=1 -DPGSQL_LIB=libpq.so.5 -DSPLIT_SYMBOLS=ON -DUSE_BISON=ON -DUSE_FLEX=ON -DUSE_SYSLOG=1 -DWITH_EXPAT=ON -DWITH_ICONV=ON -DWITH_MYSQL=ON -DWITH_ODBC=ON -DWITH_PGSQL=ON -DWITH_RE2=ON -DWITH_STEMMER=ON -DWITH_ZLIB=ON
Host OS is Linux 01ea43a41e6c 4.8.0-45-generic #48~16.04.1-Ubuntu SMP Fri Mar 24 12:46:56 UTC 2017 x86_64 x86_64 x86_64 GNU/Linux
Stack bottom = 0x7f23e9ffaeff, thread stack size = 0x100000
Trying manual backtrace:
Something wrong with thread stack, manual backtrace may be incorrect (fp=0x4)
Wrong stack limit or frame pointer, manual backtrace failed (fp=0x4, stack=0x7f23ea000000, stacksize=0x100000)
Trying system backtrace:
[Sun Nov 12 09:31:17.337 2017] [27498] watchdog: main process 27499 killed dirtily with signal 11, will be restarted
[Sun Nov 12 09:31:17.338 2017] [27498] watchdog: main process 24605 forked ok
[Sun Nov 12 09:31:17.387 2017] [24605] listening on all interfaces, port=9312
[Sun Nov 12 09:31:17.387 2017] [24605] listening on all interfaces, port=9306
[Sun Nov 12 09:31:27.539 2017] [24605] WARNING: wordlist size mismatch (size=18, checkpoints=0)
[Sun Nov 12 09:31:48.719 2017] [24605] last message repeated 5 times
[Sun Nov 12 09:31:48.719 2017] [24605] binlog: replaying log /var/lib/sphinx//binlog.043

Find error in /var/log/messages:
kernel: : [423829.349058] searchd[27523]: segfault at 54 ip 00007f24f8f034d3 sp 00007f23e97d5fb8 error 4 in libstdc++.so.6.0.19[7f24f8e8e000+e9000]

I tried to execute the query once more, it was executed correctly.

expand_keywords as a query option

Currently expand_keywords can be enabled on a index.

Would be more useful if was an OPTION per query, ie SELECT ... WHERE MATCH(...) OPTION expand_keywords=1

The index level option could remain, and just set default, the query option would just override it for that query. (maintain backwards compatibility)

Sharding capabilities

As far as I understand "Sphinx" can't shard an index across multiple nodes.
Did "Manticore" inherit this limitation? Cannot find an answer in the docs.

Some strange warnings during building latest Manticore

http://slack.manticoresearch.com/

Some strange warnings during building latest Manticore code from github repo was discovered:

/git-repos/manticore-git/src/sphinxexpr.cpp:2625:12: warning: ‘G_FUNC_HASH_CHECK’ defined but not used [-Wunused-variable]
 static int G_FUNC_HASH_CHECK /git-repos/manticore-git/src/sphinxexpr.cpp:2625:12: warning: ‘G_FUNC_HASH_CHECK’ defined but not used [-Wunused-variable]
 static int G_FUNC_HASH_CHECK = FuncHashCheck();K = FuncHashCheck();
 
[ 65%] Building CXX object src/CMakeFiles/searchd.dir/searchd.cpp.o
/git-repos/manticore-git/src/searchd.cpp: In member function ‘virtual NetEvent_e CSphWakeupEvent::Tick(DWORD, CSphVector<ISphNetAction*>&, CSphNetLoop*)’:
/git-repos/manticore-git/src/searchd.cpp:20992:48: warning: ignoring return value of ‘ssize_t read(int, void*, size_t)’, declared with attribute warn_unused_result [-Wunused-result]
    ::read ( m_iReadFD, &uVal, sizeof ( uVal ) );

[ 85%] Building CXX object src/CMakeFiles/gmanticoretest.dir/gtests_globalstate.cpp.o
    /git-repos/manticore-git/src/gtests_globalstate.cpp:66:32: warning: ‘env’ defined but not used [-Wunused-variable]
     ::testing::Environment * const env = ::testing::AddGlobalTestEnvironment ( new Environment );
                                    ^
[ 86%] Building CXX object src/CMakeFiles/gmanticoretest.dir/gtests_searchd.cpp.o
    In file included from /git-repos/manticore-git/src/gtests_searchd.cpp:10:0:
    /git-repos/manticore-git/src/searchd.cpp: In member function ‘virtual NetEvent_e CSphWakeupEvent::Tick(DWORD, CSphVector<ISphNetAction*>&, CSphNetLoop*)’:
    /git-repos/manticore-git/src/searchd.cpp:20992:48: warning: ignoring return value of ‘ssize_t read(int, void*, size_t)’, declared with attribute warn_unused_result [-Wunused-result]
        ::read ( m_iReadFD, &uVal, sizeof ( uVal ) );

Sphinx 2.3.2: segfault in some queries

Just a heads up about a possibly unresolved sphinx bug: before applying this patch I was regularly seeing searchd segfaults in my Sphinx 2.3.2 install

http://sphinxsearch.com/bugs/view.php?id=2644

Group N By for MVAs

Group N By works great for scalar Attributes, and singular Group By works great for MVAs.

This is a request to be able to use both concepts at the same time.

For reference:

select id,context_ids,groupby(),count(*) from sample8D where match('bridge') group 3 by context_ids limit 10;
ERROR 1064 (42000): index sample8D: internal error: unhandled sorting mode (match-sort=4, group=1, group-sort=4)

FATAL: CRASH DUMP - searchd

Manticore 2.4.1
Ubuntu Xenial
12 RT Indexes
1 local index updated/rotated every minute.

------- FATAL: CRASH DUMP -------
[Fri Nov 24 07:12:26.146 2017] [21110]

--- crashed SphinxAPI request dump ---
AAABGQAAAYAAAAAAAAAAAQAAAGQAAAAUAAAABgAAAAAAAAAEAAAAF3VwbG9hZCBERVNDLHVwbG9hZCBERVNDAAAA
AAAAAAAAAAAScmVhbHRpbWVfbWVkaWFfOTQxAAAAAQAAAAAAAAAAAAAAAAAAAAAAAAAGAAAAEG1vZGVy
YXRpb25zdGF0dXMAAAAAAAAAAgAAAAAAAAAAAAAAAAAAAAEAAAAAAAAABXZob3N0AAAAAAAAAAEAAAAA
AAADrQAAAAAAAAALcGFyZW50Z3JvdXAAAAAAAAAAAQAAAAAACtecAAAAAAAAAAZzdGF0dXMAAAAAAAAA
AQAAAAAAAAADAAAAAAAAAAdjb250ZXh0AAAAAAAAAAEAAAAAAAAAAQAAAAAAAAAGaGlkZGVuAAAA
AAAAAAEAAAAAAAAAAAAAAAAAAAAAAAAAAAAPQkAAAAALQGdyb3VwIGRlc2MAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAASo=
--- request dump end ---
Sphinx 2.4.1 3b31a97@171017 id64-release
Handling signal 6
-------------- backtrace begins here ---------------
Program compiled with 5.4.0
Configured with flags: Configured by CMake with these definitions: -DCMAKE_BUILD_TYPE=RelWithDebInfo -DDL_UNIXODBC=1 -DUNIXODBC_LIB=libodbc.so.2 -DDL_EXPAT=1 -DEXPAT_LIB=libexpat.so.1 -DDL_MYSQL=1 -DMYSQL_LIB=libmysqlclient.so.20 -DMYSQL_CONFIG_EXECUTABLE=/usr/bin/mysql_config -DDL_PGSQL=1 -DPGSQL_LIB=libpq.so.5 -DSPLIT_SYMBOLS=ON -DUSE_BISON=ON -DUSE_FLEX=ON -DUSE_SYSLOG=1 -DWITH_EXPAT=ON -DWITH_ICONV=ON -DWITH_MYSQL=ON -DWITH_ODBC=ON -DWITH_PGSQL=ON -DWITH_RE2=ON -DWITH_STEMMER=ON -DWITH_ZLIB=ON
Host OS is Linux 458262cc09b5 4.8.0-45-generic #48~16.04.1-Ubuntu SMP Fri Mar 24 12:46:56 UTC 2017 x86_64 x86_64 x86_64 GNU/Linux
Stack bottom = 0x7f1328828ef7, thread stack size = 0x100000
Trying manual backtrace:
Something wrong with thread stack, manual backtrace may be incorrect (fp=0x4)
Wrong stack limit or frame pointer, manual backtrace failed (fp=0x4, stack=0x7f1328830000, stacksize=0x100000)
Trying system backtrace:
begin of manual symbols:
64d168
4ccf05
7f15011c0390
7f150015b428
7f150015d02a
7f150019d7ea
7f15001a8651
7f15001aa282
656739
525537
766210
742c1b
508886
50e0d0
50fede
5172d2
5185ac
518b39
519eb5
4c8ecf
65646f
7f15011b66ba
7f150022d3dd
-------------- backtrace ends here ---------------
Please, create a bug report in our bug tracker (http://sphinxsearch.com/bugs) and attach there:
a) searchd log, b) searchd binary, c) searchd symbols.
Look into the chapter 'Reporting bugs' in the documentation
(/usr/share/doc/sphinx/sphinx.txt or http://sphinxsearch.com/docs/current.html#reporting-bugs)
--- BT to source lines (depth 23): ---
------- FATAL: CRASH DUMP -------
[Fri Nov 24 07:12:26.146 2017] [21110]

--- crashed SphinxAPI request dump ---
AAABGQAAAXAAAAAAAAAAAQAAAAAAAAABAAAABgAAAAAAAAAEAAAAF3VwbG9hZCBERVNDLHVwbG9hZCBERVNDAAAA
AAAAAAAAAAAScmVhbHRpbWVfbWVkaWFfOTQxAAAAAQAAAAAAAAAAAAAAAAAAAAAAAAAGAAAAEG1vZGVy
YXRpb25zdGF0dXMAAAAAAAAAAQAAAAAAAAABAAAAAAAAAAV2aG9zdAAAAAAAAAABAAAAAAAAA60AAAAA
AAAAA2dpZAAAAAAAAAABAAAAAAAK2IIAAAAAAAAABnN0YXR1cwAAAAAAAAABAAAAAAAAAAMAAAAAAAAA
B2NvbnRleHQAAAAAAAAAAQAAAAAAAAABAAAAAAAAAAZoaWRkZW4AAAAAAAAAAQAAAAAAAAAAAAAA
AAAAAAAAAAAAAA9CQAAAAAtAZ3JvdXAgZGVzYwAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAABKg==
--- request dump end ---
Sphinx 2.4.1 3b31a97@171017 id64-release
Handling signal 11
-------------- backtrace begins here ---------------
Program compiled with 5.4.0
Configured with flags: Configured by CMake with these definitions: -DCMAKE_BUILD_TYPE=RelWithDebInfo -DDL_UNIXODBC=1 -DUNIXODBC_LIB=libodbc.so.2 -DDL_EXPAT=1 -DEXPAT_LIB=libexpat.so.1 -DDL_MYSQL=1 -DMYSQL_LIB=libmysqlclient.so.20 -DMYSQL_CONFIG_EXECUTABLE=/usr/bin/mysql_config -DDL_PGSQL=1 -DPGSQL_LIB=libpq.so.5 -DSPLIT_SYMBOLS=ON -DUSE_BISON=ON -DUSE_FLEX=ON -DUSE_SYSLOG=1 -DWITH_EXPAT=ON -DWITH_ICONV=ON -DWITH_MYSQL=ON -DWITH_ODBC=ON -DWITH_PGSQL=ON -DWITH_RE2=ON -DWITH_STEMMER=ON -DWITH_ZLIB=ON
Host OS is Linux 458262cc09b5 4.8.0-45-generic #48~16.04.1-Ubuntu SMP Fri Mar 24 12:46:56 UTC 2017 x86_64 x86_64 x86_64 GNU/Linux
Stack bottom = 0x7f1333df6ef7, thread stack size = 0x100000
Trying manual backtrace:
Something wrong with thread stack, manual backtrace may be incorrect (fp=0x4)
Wrong stack limit or frame pointer, manual backtrace failed (fp=0x4, stack=0x7f1333e00000, stacksize=0x100000)
Trying system backtrace:
begin of manual symbols:
64d168
4ccf05
7f15011c0390
765daf
742c1b
508886
50e0d0
50fede
5172d2
5185ac
518b39
519eb5
4c8ecf
65646f
7f15011b66ba
7f150022d3dd
-------------- backtrace ends here ---------------
Please, create a bug report in our bug tracker (http://sphinxsearch.com/bugs) and attach there:
a) searchd log, b) searchd binary, c) searchd symbols.
Look into the chapter 'Reporting bugs' in the documentation
(/usr/share/doc/sphinx/sphinx.txt or http://sphinxsearch.com/docs/current.html#reporting-bugs)
--- BT to source lines (depth 16): ---
[Fri Nov 24 07:22:29.421 2017] [8251] watchdog: main process 21110 killed dirtily with signal 11, core dumped, will be restarted

Build fail on Alpine

Can't build manticore from git in Alpine.

[ 15%] Building CXX object src/CMakeFiles/libsphinx.dir/sphinx.cpp.o
In file included from /usr/include/limits.h:8:0,
                 from /usr/src/manticore/src/sphinxstd.h:55,
                 from /usr/src/manticore/src/sphinx.h:43,
                 from /usr/src/manticore/src/sphinx.cpp:16:
/usr/src/manticore/src/sphinx.cpp:7849:20: error: expected unqualified-id before numeric constant
  static const int  PAGE_SIZE = 1<<MAX_BITS;
                    ^
make[2]: *** [src/CMakeFiles/libsphinx.dir/build.make:96: src/CMakeFiles/libsphinx.dir/sphinx.cpp.o] Error 1
make[1]: *** [CMakeFiles/Makefile2:1000: src/CMakeFiles/libsphinx.dir/all] Error 2
make[1]: *** Waiting for unfinished jobs....

Dockerfile for build:

FROM alpine

RUN apk add --no-cache \
    git \
    cmake \
    make \
    g++ \
    mariadb-dev \
    bison \
    flex-dev

RUN mkdir -p /usr/src \
    && git clone --depth=1 https://github.com/manticoresoftware/manticore.git /usr/src/manticore

RUN cd /usr/src/manticore \
    && cmake -D WITH_MYSQL=1 ../manticore \
    && make -j4 install

Sorting JSON integer

> select id, json.int from test1 order by json.int asc;
+------+----------+
| id   | json.int |
+------+----------+
|    1 | 1        |
|   11 | 1024     |
|    8 | 128      |
|    5 | 16       |
|   15 | 16384    |
|    2 | 2        |
|   12 | 2048     |
|    9 | 256      |
|    6 | 32       |
|   16 | 32768    |
|    3 | 4        |
|   13 | 4096     |
|   10 | 512      |
|    7 | 64       |
|    4 | 8        |
|   14 | 8192     |
+------+----------+

Why this sort?
Using the INTEGER () function affects performance?

Data in test.csv

1,,{"int":1}
2,,{"int":2}
3,,{"int":4}
4,,{"int":8}
5,,{"int":16}
6,,{"int":32}
7,,{"int":64}
8,,{"int":128}
9,,{"int":256}
10,,{"int":512}
11,,{"int":1024}
12,,{"int":2048}
13,,{"int":4096}
14,,{"int":8192}
15,,{"int":16384}
16,,{"int":32768}

Sphinx config:

#sphinx.conf

source src1
{
	type = csvpipe
	csvpipe_command = cat test.csv
	csvpipe_field = name
	csvpipe_attr_json = json
}

index test1
{
	source			= src1
	path			= /var/lib/sphinx/data/test1
}

searchd
{
	listen			= 9306:mysql41
	pid_file		= /var/lib/sphinx/searchd.pid
	binlog_path		= /var/lib/sphinx/data
}

Facet vs multiquery edge cases

Конфиг Sphinx:

searchd
{
    listen = 9316
    listen = 9306:mysql41
    
    pid_file = c:\sphinx\searchd.pid
    log = c:\sphinx\log\log.txt
    query_log = c:\sphinx\log\query_log.txt
    binlog_path = c:\sphinx\binlog
}

source test
{
    type = csvpipe
    
    csvpipe_attr_uint = gid
    
    csvpipe_attr_uint = brand_id
    csvpipe_field_string = brand_name
    
    csvpipe_attr_uint = color_id
    csvpipe_field_string = color_name
    
    csvpipe_delimiter = ;
    csvpipe_command = \
        @echo 1;5;7;Apple;9;Black &\
        @echo 2;5;7;Apple;10;White &\
        @echo 3;6;8;Samsung;9;Black &\
        @echo 4;6;8;Samsung;10;White &\
        
}

index test
{
    source = test
    path = c:\sphinx\index\test
}

SphinxQL count returns incorrect value.

With the sample data below, there are only 12 documents that match webapp however when you query the count you get 23.

mysql> select count(*) from messages_dist where match('webapp');
+----------+
| count(*) |
+----------+
|       23 |
+----------+
1 row in set (0.02 sec)

mysql> select id from messages_dist where match('webapp');
+----------+
| id       |
+----------+
|     3015 |
| 10004761 |
| 10004762 |
| 10004763 |
| 10004900 |
| 10004923 |
| 10004924 |
| 10005007 |
| 10005008 |
| 10005030 |
| 10005031 |
| 10005032 |
+----------+
12 rows in set (0.03 sec)

How can I use UUID IDs?

In my Postgresql table I use UUID type for IDs, but the documentation is saying that I have to use only 32/64-bit IDs. Is there an any possible way to use 128-bit UUID IDs in the Manticore?

Facet vs count distinct

INTERNAL ERROR: column '@distinct/count(distinct gid)' not found in result set schema

Конфиг Sphinx:

searchd
{
    listen = 9316
    listen = 9306:mysql41
    
    pid_file = c:\sphinx\searchd.pid
    log = c:\sphinx\log\log.txt
    query_log = c:\sphinx\log\query_log.txt
    binlog_path = c:\sphinx\binlog
}

source test
{
    type = csvpipe
    
    csvpipe_attr_uint = gid
    
    csvpipe_attr_uint = brand_id
    csvpipe_field_string = brand_name
    
    csvpipe_attr_uint = color_id
    csvpipe_field_string = color_name
    
    csvpipe_delimiter = ;
    csvpipe_command = \
        @echo 1;5;7;Apple;9;Black &\
        @echo 2;5;7;Apple;10;White &\
        @echo 3;6;8;Samsung;9;Black &\
        @echo 4;6;8;Samsung;10;White &\
        
}

index test
{
    source = test
    path = c:\sphinx\index\test
}

Запрос:

select gid, count(distinct gid) from test group by gid
facet brand_id, brand_name by brand_id order by count(*) desc
facet color_id, color_name by color_id order by count(*) desc;

Возникает ошибка:
INTERNAL ERROR: column '@distinct/count(distinct gid)' not found in result set schema

А также в searchd:
WARNING: bailing on failed MySQL header (client=127.0.0.1:10003(6)), error: 10053 'WSA error 10053', sock=316

Should I use manticore instead of sphinxsearch?

Hi, maybe I missing something, but why did the fork appear?
I planning create e-commerce website, and had already decided to take sphinxsearch, and found your fork.

Ability for joined-fields/MVAs to reuse ranges from sql_query_range

instead of

    sql_attr_multi = bigint tag from ranged-query; \
        SELECT id, tag FROM tags WHERE id>=$start AND id<=$end; \
        SELECT MIN(id), MAX(id) FROM tags

Allow

  sql_query_range = SELECT MIN(id), MAX(id) FROM documents
   sql_attr_multi = bigint tag from ranged-query; \
        SELECT id,tag_id FROM tags WHERE id>=$start AND id<=$end

It may look a small distinction, but it allows for much easier sharding. Doesn't matter if it runs the same sql_query_range query again when evaluating sql_attr_multi, or just remembers the min/max numbers. Its just that so don't have to define a individual query.
The indexes created by inheritance, can JUST redefine sql_query_range and it will be used without having to include the sql_attr_multi again in the additional indexes! (with their duplication of the main range.

So can do...

source shard0 {
....
    sql_query_range = SELECT 0, 999
    sql_range_step = 100
    sql_query = SELECT id, title, description FROM document WHERE id>=$start AND id<=$end
    sql_attr_multi = bigint tag_id from ranged-query; \
        SELECT id, tag_id FROM tags WHERE id>=$start AND id<=$end
....
}

source shard1:shard0 {
    sql_query_range = SELECT 1000, 1999
}
source shard2:shard0 {
    sql_query_range = SELECT 2000, 2999
}

removal of the 4GB index size limit for string/JSON fields

it would be great if the current, per index limit of 4GB for the total size of string/JSON fields was removed. currently sharding is the only workaround.

if needed i can provide a sample XML that cannot be correctly indexed because of this limit.

thanks!

Request for community: JSON data

We going to add more features related to JSON index attributes and need many test cases for that. That is why we ask to give us your big JSON data and how you use it, such as - indexes with JSON attributes, source data, queries, query process time, index sizes.

Build does not set SYSCONFDIR

The new cmake build does not set SYSCONFDIR, this leaves the default config file for the binaries as ./sphinx.conf

brew install manticore ?

Hi, what efforts if any are going on to get manticore available in Homebrew? Or any other ports system? How about Windows Chocolatey? I feel there should be issues or milestones for this, or ideas into how to get people on board with creating and maintaining builds and packages for for various package manager platforms.

Morphology only for certain fields

Would be nice to be able to only apply morphology to certain fields (or exclude applying it certain fields!) during indexing.

Know it would then mean different tokens exist in index for different fields (so a if a query keywoord is morphed, wont match the unmorphed filed) - but this could be mitigated by using expand_keywords on the index. (then the excluded fields, would only match via the 'exact keywords' not morphed at all)

Basically to avoid having to do

@!(place) Huntly | @place =Huntly

Use existing mysql database

Hi all!

I've just discovered this packaged, and was wondering how I can start using it with an existing mysql database.

Do I have to index every time the database changes? Or just once?

Found this bit in the docs, but find it quite confusing / overwhelming - seems to be just bunch of commands with no explanation of what they do.

Is it possible to elaborate bit more on this, please?

Thanks,

max_children problem

In my case the option max_children with the value 0 doesn't work properly. After some time of work the searchd daemon is freezing and do not respond to connections. This is the part of my config file:

searchd
{
        listen                                  = 0.0.0.0:3312
        listen                                  = 0.0.0.0:9306:mysql41
        mysql_version_string    = 5.1.73
        log                                     = /usr/local/var/log/searchd.log

        query_log                       = /usr/local/var/log/query.log

        read_timeout            = 5

        workers = fork
        max_children            = 0

        pid_file                        = /usr/local/var/log/searchd.pid

        seamless_rotate         = 1

        preopen_indexes         = 1
        unlink_old                      = 1
        binlog_path = #
        attr_flush_period = 300

        mva_updates_pool = 64M

        sphinxql_state = /usr/local/var/data/sphinxql_state.sql
}

When i set max_children the exact value everything is fine.

I'm using Manticore 2.4.1 3b31a97@171017 id64-release

What is going wrong? Is it a bug or i need to specify some other options? Hope on your responce.

daemon crash on snipept generation

sphinx crashed

Feature Request: X-Bit IDs

One thing I've found myself running into is with larger data sets and the potential for hash collisions when generating doc ids. With 64 bits, the 50% chance threshold of a hash collision with_each_hash_generated is somewhere around 5 billion entries. At 192 million hashes, the odds are 1 in 1,000 hashes generated. In order to compensate for this, it requires a separate lookup table of larger hashes (e.g. MD5) to 64 bit index IDs.

I'd love to see the option of specifying the bit length for the doc IDs (e.g. 128-bit ids, 256-bit ids, etc for an index). I'm guessing this isn't as straightforward as changing the byte length of the struct/class property, so if someone can give me some ideas on what pieces of the code would need to be changed, I can look and see if it's something I can do.

RT index stores string attributes after they got stripped by html_stripper that is wrong

Inconsistent behavior of html_strip

html_strip has an incosistent behavior on plain and realtime indexes for field_string attribute

plain index:

index plain_index
{
    type=plain
    html_strip=1
    ...
}

find index and config attached

Query:

select * from plain_index;

+----+-------------------------------+
| id | content |
+------------------------------------+
| 1 | <escape_p>some <escape_b>html</escape_b> code</escape_p> |
+----+-------------------------------+
1 row in set (0.03 sec)


select * from rt_index;

+----+-------------------------------+
| id | content |
+------------------------------------+
| 1 | some html code |
+----+-------------------------------+
1 row in set (0.02 sec)

Negative Assertion Full-Text Operator

Match a keyword, but NOT when preceded/followed by some word. Not sure exact syntax, perhaps "Church -Street" (in the quotes). Would match all instances of Church, but NOT one in "Church Street".

Query: "Church -Street"
Doc1: St. Mary's Church - Match (has Church)
Doc2: Cars on Church Street - NOT Match (has "Church Street")
Doc3: St. Mary's Church at end of Church Street - Match (has Church on its own)

The last document exemplifies why Church -"Church Street" almost but not quite works. The negative term would exclude the result despite the other Church match.

Alternatively it could be a 'Not Near' operator somehow. As in Church NOT NEAR/2 Street

crash on excerpt via some kind of SQL magic (SpinxSE?

---- Versions:
Sphinx 2.2.11-id64-release (95ae9a6)
10.1.20-MariaDB-1~jessie mariadb.org binary distribution
on debian 8

--- Stored Procedure:

CREATE DEFINER=`root`@`127.0.0.1` FUNCTION `SphinxBuildExcerpts`(docs TEXT, words VARCHAR(1024)) RETURNS varchar(1024) CHARSET utf8
    NO SQL
BEGIN
    RETURN sphinx_snippets(docs, 'INDEX', words, 'sphinx://127.0.0.1/' [^] AS sphinx, '[b]' AS before_match, '[/b]' AS after_match, 150 AS `limit`, 20 AS around);
END

---- SQL
Launch this SQL command with word empty:

SELECT SphinxBuildExcerpts('hello the world', '');

--- REGRESSION

Work fine with 2.2.10
Work fine when work is not empty

--- CRASH

------- FATAL: CRASH DUMP -------
[Mon Jan 16 19:00:09.825 2017] [ 1963]

--- crashed SphinxAPI request dump ---
AAEBBAAAAG8AAAAAAAAAAQAAAA9BZHZlcnRpc2VtZW50czAAAAAAAAAAA1tiXQAAAARbL2JdAAAABSAuLi4gAAAA
lgAAABQAAAAAAAAAAAAAAAEAAAAFaW5kZXgAAAAAAAAAAQAAAA9oZWxsbyB0aGUgd29ybGQ=
--- request dump end ---
Sphinx 2.2.11-id64-release (95ae9a6)
Handling signal 11
-------------- backtrace begins here ---------------
Program compiled with x86_64-linux-gnu-gcc 4.9.2
Configured with flags: '--host=x86_64-linux-gnu' '--build=x86_64-linux-gnu' '--prefix=/usr' '--mandir=${prefix}/share/man' '--infodir=${prefix}/share/info' '--localstatedir=/var/lib/sphinxsearch' '--sysconfdir=/etc/sphinxsearch' '--with-mysql' '--with-pgsql' '--enable-id64' '--with-libstemmer' '--with-re2' '--with-unixodbc' '--with-syslog' 'CFLAGS=-Wall -g -O3' 'LDFLAGS=-Wl,-z,defs -pthread' 'build_alias=x86_64-linux-gnu' 'host_alias=x86_64-linux-gnu'
Host OS is Linux debian8-64 3.16.0-4-amd64 0000001 SMP Debian 3.16.7-ckt11-1+deb8u3 (2015-08-04) x86_64 GNU/Linux
Stack bottom = 0x7f490a86aeff, thread stack size = 0x100000
Trying manual backtrace:
Something wrong with thread stack, manual backtrace may be incorrect (fp=0xb)
Wrong stack limit or frame pointer, manual backtrace failed (fp=0xb, stack=0x7f490a870000, stacksize=0x100000)
Trying system backtrace:
begin of system symbols:
/usr/bin/searchd[0x59253b]
/usr/bin/searchd[0x410354]
/lib/x86_64-linux-gnu/libpthread.so.0(+0xf890)[0x7f490f70a890]
/lib/x86_64-linux-gnu/libc.so.6(strlen+0x2a)[0x7f490dec6c3a]
/usr/bin/searchd[0x55df22]
/usr/bin/searchd[0x55ee71]
/usr/bin/searchd[0x5629a8]
/usr/bin/searchd[0x44f495]
/usr/bin/searchd[0x45047b]
/usr/bin/searchd[0x45e7da]
/usr/bin/searchd[0x45ef48]
/usr/bin/searchd[0x40907f]
/usr/bin/searchd[0x59a94f]
/lib/x86_64-linux-gnu/libpthread.so.0(+0x8064)[0x7f490f703064]
/lib/x86_64-linux-gnu/libc.so.6(clone+0x6d)[0x7f490df2d62d]
-------------- backtrace ends here ---------------
Please, create a bug report in our bug tracker (http://sphinxsearch.com/bugs [^]) and attach there:
a) searchd log, b) searchd binary, c) searchd symbols.
Look into the chapter 'Reporting bugs' in the documentation
(/usr/share/doc/sphinx/sphinx.txt or http://sphinxsearch.com/docs/current.html#reporting-bugs [^])
--- BT to source lines (depth 15): ---
??:0
??:0
??:0
??:0
??:0
??:0
??:0
??:0
??:0
??:0
??:0
??:0
??:0
??:0
??:0
--- BT to source lines finished ---
--- 1 active threads ---
thd 0, proto sphinxapi, state query, command excerpt
------- CRASH DUMP END -------

Bad killllist query is not reported

How to test: use a normal plain index, add a sql_query_killlist with some bad content. Run indexer. It will not output and warning or error about the sql_query_killlist being. But it does if you have a joined field, however it's not the error message the killlist code should throw it ( killlist query failed: is missing), but a general sql error.
Failed killlist query is not handled well, as CSphSource_SQL::IterateKillListStart returns true if sql_query_killist is set and query runs with success. It returns false for 2 situations: if sql_query_killlist is empty and if the query fails. The code from Index:Build doesn't do anything if IterateKillListStart is false (because false means no killlist declared).
This can be reproduced in both master and rel22 branches.

daemon crash on query wo indexes (query via old API)

------- FATAL: CRASH DUMP -------
[Tue Nov 22 07:07:54.912 2016] [30691]

--- crashed SphinxAPI request dump ---
AAABGQAAAJYAAAAAAAAAAQAAAAAAAAAUAAAAAAAAAAAAAAAAAAAAAAAAAArOkc6TzqnOk86XAAAAAAAAAAAAAAAB
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA+gAAAALQGdyb3VwIGRlc2MAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAASo=
--- request dump end ---
Sphinx 2.2.11-id64-release (95ae9a6)
Handling signal 11
-------------- backtrace begins here ---------------
Program compiled with gcc 4.4.7
Configured with flags: '--with-libstemmer'
Host OS is Linux nb2c.isol-servers.net 2.6.32-642.4.2.el6.x86_64 0000001 SMP Tue Aug 23 19:58:13 UTC 2016 x86_64 x86_64 x86_64 GNU/Linux
Stack bottom = 0x7efdf20ffe7f, thread stack size = 0x100000
Trying manual backtrace:
Something wrong with thread stack, manual backtrace may be incorrect (fp=0x7efdf20fd160)
Stack looks OK, attempting backtrace.
0x418e93
0x4350c0
0x4598f2
0x45c081
0x474507
0x474ce0
0x474ebc
0x4168a4
0x5b6c1d
0x7efdfc95eaa1
Something wrong in frame pointers, manual backtrace failed (fp=0)
Trying system backtrace:
begin of system symbols:
searchd[0x5abaa0]
searchd(_ZN16SphCrashLogger_c11HandleCrashEi+0x1c3)[0x418e93]
/lib64/libpthread.so.0(+0xf7e0)[0x7efdfc9667e0]
searchd[0x4350c0]
searchd[0x4598f2]
searchd[0x45c081]
searchd[0x474507]
searchd[0x474ce0]
searchd(_Z13HandlerThreadPv+0x3c)[0x474ebc]
searchd(_ZN16SphCrashLogger_c13ThreadWrapperEPv+0x44)[0x4168a4]
searchd(_Z20sphThreadProcWrapperPv+0x1d)[0x5b6c1d]
/lib64/libpthread.so.0(+0x7aa1)[0x7efdfc95eaa1]
/lib64/libc.so.6(clone+0x6d)[0x7efdfb8e9aad]
-------------- backtrace ends here ---------------
Please, create a bug report in our bug tracker (http://sphinxsearch.com/bugs [^]) and attach there:
a) searchd log, b) searchd binary, c) searchd symbols.
Look into the chapter 'Reporting bugs' in the documentation
(/usr/share/doc/sphinx/sphinx.txt or http://sphinxsearch.com/docs/current.html#reporting-bugs [^])
--- BT to source lines (depth 13): ---
--- BT to source lines finished ---
--- 1 active threads ---
thd 0, proto sphinxapi, state query, command search
------- CRASH DUMP END -------
[Tue Nov 22 07:07:54.935 2016] [18225] watchdog: main process 30691 crashed via CRASH_EXIT (exit code 2), will be restarted
[Tue Nov 22 07:07:54.935 2016] [18225] watchdog: main process 30723 forked ok
[Tue Nov 22 07:07:54.939 2016] [30723] Reloading the config
[Tue Nov 22 07:07:54.943 2016] [30723] Reconfigure the daemon
[Tue Nov 22 07:07:54.945 2016] [30723] listening on 127.0.0.1:9314
[Tue Nov 22 07:07:54.945 2016] [30723] listening on all interfaces, port=9308
[Tue Nov 22 07:07:55.024 2016] [30723] accepting connections

Return the Query text in the CALL PQ resultset

Been playing with the new "percolate" indexes. Seems very promising. Performance is nice. (the CALL PQ takes about 0.5 seconds on a 10k query index. My own homegrown percolate system takes about 3 seconds on same data - basically does some prefitering with a query index, but uses CALL SNIPPET(query_mode=1) to do the final exact matching - needs passing the whole document over the wire many times, avoided with CALL PQ)

... my main feature request, is that the CALL PQ itself can return the actual query text. So dont have to lookup the queries again.

(this is particularly important as select * from pq where UID IN(6308,7564,2417); does not work, returns all rows :( )

Otherwise more an annoyance is the inconsistency in column names. describe has id,text,gid, SELECT has UID,Query,Tags,Filter, and CALL PQ has Query (which now is the UID, not query-text as in SELECT)

Final bit of feedback, seems easy to create duplicate id'ed queries
https://gist.github.com/barryhunter/a6f46560287f082d632f7b82151cb401
(havent tested behaviour with REPLACE into yet)

Allow order more than 5 fields

https://github.com/manticoresoftware/manticore/blob/master/src/sphinxsort.cpp#L3584