sphinxse table: Lost connection to MySQL server during query

Polyglot Projects Sphinx & Full-Text Search
1

I have successfully installed sphinx 1.10-beta. I have also installed sphinxse for same
under MySQL Percona (5.1.53). I am able to create index and query against searchd daemon
successfully using PHP.

When I tried to use sphinxse, I was able to create following sample table successfully.

CREATE TABLE t1
(
id INTEGER UNSIGNED NOT NULL,
weight INTEGER NOT NULL,
query VARCHAR(3072) NOT NULL,
blog_id INTEGER,
INDEX (query)
) ENGINE=SPHINX CONNECTION=“sphinx://localhost:9312/devidx”;

I get an error when running a select from this table.

mysql> SELECT * FROM t1 WHERE query=‘Part 100’;
ERROR 2013 (HY000): Lost connection to MySQL server during query

Following is from mysql log file.

110124 21:38:31 - mysqld got signal 11 ;
This could be because you hit a bug. It is also possible that this binary
or one of the libraries it was linked against is corrupt, improperly built,
or misconfigured. This error can also be caused by malfunctioning hardware.
We will try our best to scrape up some info that will hopefully help diagnose
the problem, but since we have already crashed, something is definitely wrong
and this may fail.

key_buffer_size=16777216
read_buffer_size=262144
max_used_connections=1
max_threads=151
threads_connected=1
It is possible that mysqld could use up to
key_buffer_size + (read_buffer_size + sort_buffer_size)*max_threads = 133990 K
bytes of memory
Hope that’s ok; if not, decrease some variables in the equation.

thd: 0xad69440
Attempting backtrace. You can use the following information to find out
where mysqld died. If you see no messages after this, something went
terribly wrong…
stack_bottom = 0x418880e0 thread_stack 0x40000
/usr/local/mysql/libexec/mysqld(my_print_stacktrace+0x24) [0x824924]
/usr/local/mysql/libexec/mysqld(handle_segfault+0x320) [0x57d750]
/lib64/libpthread.so.0 [0x3c8b80eb10]
/lib64/libpthread.so.0(pthread_mutex_lock+0) [0x3c8b808ca0]
/usr/local/mysql/libexec/mysqld(thr_lock+0x4c) [0x82925c]
/usr/local/mysql/libexec/mysqld(thr_multi_lock+0xaa) [0x8296da]
/usr/local/mysql/libexec/mysqld(mysql_lock_tables(THD*, st_table**, unsigned int,
unsigned int, bool*)+0x24c) [0x575f1c]
/usr/local/mysql/libexec/mysqld(lock_tables(THD*, TABLE_LIST*, unsigned int,
bool*)+0x308) [0x5c6548]
/usr/local/mysql/libexec/mysqld(open_and_lock_tables_derived (THD*, TABLE_LIST*,
bool)+0x3c) [0x5ccd6c]
/usr/local/mysql/libexec/mysqld [0x58669f]
/usr/local/mysql/libexec/mysqld(mysql_execute_command(THD*)+ 0x3fd) [0x58964d]
/usr/local/mysql/libexec/mysqld(mysql_parse(THD*, char*, unsigned int, char
const**)+0x549) [0x58f7f9]
/usr/local/mysql/libexec/mysqld(dispatch_command(enum_server _command, THD*, char*,
unsigned int)+0xa31) [0x590231]
/usr/local/mysql/libexec/mysqld(do_command(THD*)+0x120) [0x590ec0]
/usr/local/mysql/libexec/mysqld(handle_one_connection+0x5c7) [0x582cc7]
/lib64/libpthread.so.0 [0x3c8b80673d]
/lib64/libc.so.6(clone+0x6d) [0x3c8acd3f6d]
Trying to get some variables.
Some pointers may be invalid and cause the dump to abort…
thd->query at 0xadc0750 = SELECT * FROM t1 WHERE query=‘Part 100’
thd->thread_id=1
thd->killed=NOT_KILLED
The manual page at [URL]http://dev.mysql.com/doc/mysql/en/crashing.html[/URL] contains
information that should help you find out what is causing the crash.
110124 21:38:31 mysqld_safe Number of processes running now: 0
110124 21:38:31 mysqld_safe mysqld restarted
110124 21:38:31 [Warning] ‘–skip-locking’ is deprecated and will be removed in a future
release. Please use ‘–skip-external-locking’ instead.
110124 21:38:31 [Note] Flashcache bypass: disabled
110124 21:38:31 [Note] Flashcache setup error is : ioctl failed

InnoDB: The InnoDB memory heap is disabled
InnoDB: Mutexes and rw_locks use GCC atomic builtins
InnoDB: Compressed tables use zlib 1.2.3
110124 21:38:31 InnoDB: highest supported file format is Barracuda.
110124 21:38:31 Percona XtraDB ( http://www.percona.com ) 1.0.13-12.4 started; log
sequence number 66777398
110124 21:38:31 [Note] Recovering after a crash using mysql-bin
110124 21:38:31 [Note] Starting crash recovery…
110124 21:38:31 [Note] Crash recovery finished.
110124 21:38:32 [Note] Event Scheduler: Loaded 0 events
110124 21:38:32 [Note] /usr/local/mysql/libexec/mysqld: ready for connections.
Version: ‘5.1.53-log’ socket: ‘/tmp/mysql.sock’ port: 3306 Source distribution

I’ll appreciate any help with this.

I have tried rebuilding everything multiple times without any success.

Thanks

2

Some more information.

Source is xmlpipe2. Following are relevant parts of sphinx.conf.

source src1
{
type = xmlpipe2
xmlpipe_command = /usr/local/php/bin/php /tmp/sphinx/create-xmlpip2-doc.php
}

index devidx
{
source = src1
path = /tmp/sphinx/data/devidx
docinfo = extern
mlock = 0
morphology = none
charset_type = utf-8
}

indexer
{
max_iops = 0
max_xmlpipe2_field = 16M
}

searchd
{
listen = localhost:9312
log = /var/log/sphinx/searchd.log
query_log = /var/log/sphinx/query.log
read_timeout = 5
client_timeout = 300
max_children = 30
pid_file = /tmp/searchd.pid
max_matches = 1000
seamless_rotate = 1
preopen_indexes = 0
unlink_old = 1
mva_updates_pool = 1M
max_packet_size = 8M
max_filters = 256
max_filter_values = 4096
}

Following is a sample of data.

<?xml version="1.0" encoding="UTF-8"?>

sphinx:docset
sphinx:schema
<sphinx:field name=“title”/>
<sphinx:field name=“teaser”/>
<sphinx:field name=“content”/>
<sphinx:attr name=“blog_id” type=“int” bits=“16” default=“0”/>
</sphinx:schema>
<sphinx:document id=“1”>
<blog_id>6</blog_id>

Article Part 1 Article 1 teaster Article 1 content 8 Article Part 2 Article 2 teaster Article 2 content 8 Article Part 3 Article 3 teaster Article 3 content . . . . . . 6 Article Part 999 Article 999 teaster Article 999 content 1 Article Part 1000 Article 1000 teaster Article 1000 content
3

This is quite a shoot in the clouds, but can you try commenting this line from your searchd clause:

listen = localhost:9312

I have had a few crashes on 0.9.9 and it is because of the listen directive, this bug may be related and still present on 1.10.

Let me know how it goes.