[Tritonn-dev 54] view を作って show senna status すると got signal 11

Back to archive index

ICHII Takashi ichii****@schwe*****
2007年 12月 11日 (火) 23:44:24 JST


こんばんは、いちいです。


池田さんにこちらへと言われたので、バグ報告をこちらに投げさせて
いただきます。

長くなっちゃいますけど、エラーログの内容も貼り付けます。
報告だけですいません…。


* 内容
fulltext using ngramなテーブルからviewを作ってshow senna status すると
mysqld got signal 11 でクラッシュする (たんにviewつくるだけで再現しました)

* 再現手段
mysql> create table hoge (
    ->     id int not null auto_increment,
    ->     val varchar(255) not null default '',
    ->     primary key (id),
    ->     fulltext index using ngram (val)
    -> );
Query OK, 0 rows affected (0.01 sec)

mysql> create view fuga as select * from hoge;
Query OK, 0 rows affected (0.00 sec)

mysql> show senna status\G
ERROR 2013 (HY000): Lost connection to MySQL server during query  

* 環境
Linux elmo 2.6.22-2-686 #1 SMP Fri Aug 31 00:24:01 UTC 2007 i686 GNU/Linux
sf.netからダウンロードしてsupport-files/my-small.cnfほぼそのままな状態です。

* エラーログ
071211 23:18:54  mysqld started
071211 23:18:54  InnoDB: Started; log sequence number 0 49749
071211 23:18:54 [Note] /home/ichii386/usr/src/mysql-5.0/bin/mysqld: ready for connections.
Version: '5.0.45-modified'  socket: '/tmp/mysql-5.0.sock'  port: 13307  MySQL Community Server (GPL) (portions (c) Tritonn Project)
071211 23:19:15 - 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=16384
read_buffer_size=258048
max_used_connections=1
max_connections=100
threads_connected=1
It is possible that mysqld could use up to 
key_buffer_size + (read_buffer_size + sort_buffer_size)*max_connections = 31615 K
bytes of memory
Hope that's ok; if not, decrease some variables in the equation.

thd=0x8d04538
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...
Cannot determine thread, fp=0xb413f088, backtrace may not be correct.
Stack range sanity check OK, backtrace follows:
0x820f7c9
0x8316ee4
0x822738a
0x822de6f
0x8225141
Stack trace seems successful - bottom reached
Please read http://dev.mysql.com/doc/mysql/en/using-stack-trace.html and
follow instructions on how to resolve the stack trace. Resolved
stack trace is much more helpful in diagnosing the problem, so please do 
resolve it
Trying to get some variables.
Some pointers may be invalid and cause the dump to abort...
thd->query at 0x8d289b8 = show senna status
thd->thread_id=1
The manual page at http://www.mysql.com/doc/en/Crashing.html contains
information that should help you find out what is causing the crash.

Number of processes running now: 0
071211 23:19:15  mysqld restarted


以上です、よろしくお願いします。

-- 
ICHII Takashi
ichii****@schwe*****




Tritonn-dev メーリングリストの案内
Back to archive index