Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Searchd crash after SphinxQL query with WHERE json_attribute IN (1) #279

Maximusya opened this issue Nov 19, 2019 · 1 comment

Searchd crash after SphinxQL query with WHERE json_attribute IN (1) #279

Maximusya opened this issue Nov 19, 2019 · 1 comment


Copy link

@Maximusya Maximusya commented Nov 19, 2019

Manticore Search version:
Manticore 3.2.0

OS version:
Official docker image (FROM debian:stretch-slim)

Build version:
3.2.0 e526a01@191017 release

Description of the issue:
The following SphinxQL command with WHERE .. IN filtering of JSON attribute issued against non-empty index causes searchd to crash:

select * from rt where js in (1);

Steps to reproduce:

  1. Prepare simple ./etc/sphinx.conf with rt-index containing rt_attr_json:
index rt
    rt_field = text
    rt_attr_json = js
    type = rt
    path = /var/lib/manticore/data/rt

    listen           = 9306:mysql41
    log              = /var/log/manticore/searchd.log
    query_log        = /var/log/manticore/query.log
    query_log_format = sphinxql
    pid_file         = /var/run/manticore/
    binlog_path      = /var/lib/manticore/data
  1. Run official docker image mounting ./etc with the sphinx.conf prepared:
docker run --name manticoresearch-crash \
  -p 9306:9306 \
  -v $(pwd)/etc/:/etc/sphinxsearch/ \
  -v $(pwd)/data/:/var/lib/manticore/data \
  -v $(pwd)/logs/:/var/log/manticore \
  -d manticoresearch/manticore
  1. Connect with mysql client:
$ mysql -P9306 -h0
Welcome to the MySQL monitor.  Commands end with ; or \g.
Your MySQL connection id is 1
Server version: 3.2.0 e526a014@191017 release 

Copyright (c) 2000, 2019, Oracle and/or its affiliates. All rights reserved.

Oracle is a registered trademark of Oracle Corporation and/or its
affiliates. Other names may be trademarks of their respective

Type 'help;' or '\h' for help. Type '\c' to clear the current input statement.

mysql> desc rt;
| Field | Type   | Properties |
| id    | bigint |            |
| text  | field  |            |
| js    | json   |            |
3 rows in set (0.00 sec)
  1. When the index is empty, the query in question strangely succeeds (I am not sure whether this is a bug too or not):
mysql> select * from rt;
Empty set (0.00 sec)

mysql> select * from rt where js in (1);
Empty set (0.01 sec)
  1. Insert a record:
mysql> insert into rt values (1, 'text', '{"k": "v"}');
Query OK, 1 row affected (0.01 sec)

mysql> select * from rt;
| id   | js        |
|    1 | {"k":"v"} |
1 row in set (0.00 sec)
  1. Issue the query in question:
mysql> select * from rt where js in (1);

searchd crashes
Messages from log files:

[Tue Nov 19 06:49:17.218 2019] [1] listening on all interfaces, port=9306
[Tue Nov 19 06:49:17.226 2019] [15] prereading 1 indexes
[Tue Nov 19 06:49:17.226 2019] [1] accepting connections
[Tue Nov 19 06:49:17.226 2019] [15] prereaded 1 indexes in 0.000 sec
------- FATAL: CRASH DUMP -------
[Tue Nov 19 06:52:10.422 2019] [    1]

--- crashed SphinxQL request dump ---
select * from rt where js in (1)
--- request dump end ---
--- local index:rt
Manticore 3.2.0 e526a014@191017 release
Handling signal 11
-------------- backtrace begins here ---------------
Program compiled with 6.3.0
Host OS is Linux runner-fa6cab46-project-3858465-concurrent-0 4.19.23-coreos-r1 #1 SMP Mon Feb 25 23:40:01 -00 2019 x86_64 GNU/Linux
Stack bottom = 0x7f7ad8e62eff, thread stack size = 0x100000
Trying manual backtrace:
Something wrong with thread stack, manual backtrace may be incorrect (fp=0x55a57c657780)
Wrong stack limit or frame pointer, manual backtrace failed (fp=0x55a57c657780, stack=0x7f7ad8e60000, stacksize=0x100000)
Trying system backtrace:
begin of system symbols:
-------------- backtrace ends here ---------------
Please, create a bug report in our bug tracker (
and attach there:
a) searchd log, b) searchd binary, c) searchd symbols.
Look into the chapter 'Reporting bugs' in the documentation
--- BT to source lines (depth 17): ---
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 0x7c7ee0db 0x7c658da3 0xdb51a0e0 0x7c8de6b8 0x7c91ff1c 0x7c9203b9 0x7c6b2123 
0x7c6b801a 0x7c6b93bd 0x7c6b9a88 0x7c6dea8f 0x7c6bb681 0x7c6bc08e 0x7c7fd412 0x7c7f8f35 
0xdb5104a4 0xd9c8dd0f > source.txt

P.S: when the container is up again, you can delete all records from rt - and the faulty query succeeds again on empty index.
P.P.S: there is no addr2line util in the image to generate source.txt



This comment has been minimized.

Copy link

@tomatolog tomatolog commented Nov 19, 2019

I've just fixed the crash you reported at 2284da5

@tomatolog tomatolog closed this Nov 19, 2019
@tomatolog tomatolog self-assigned this Nov 19, 2019
@tomatolog tomatolog added the bug label Nov 19, 2019
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
None yet
2 participants
You can’t perform that action at this time.