Tetsuro IKEDA
te.ik****@jpta*****
2007年 12月 12日 (水) 09:59:11 JST
いちいさん、こんにちは。池田です。 バグ報告ありがとうございます。 ちょっと身に覚えがあります。 "SHOW SENNA STATUS"はsql/sql_show.ccにsenna_show_statusという 新しく作った関数で処理しているのですが、VIEWへの配慮をする コードを書いた記憶がないです。(^^; 最近、show create tableに対する処理を行うコードを読んだのですが、 http://d.hatena.ne.jp/mir/20071211/p2 VIEWへの配慮を行うコードを見て、同様のロジックがsenna_show_status にも必要と思ったしだいです。 早速修正を試みたいと思います。 いちいさん、念のためにお伺いしたいのですが、 利用されているバイナリのバージョンと種類を教えていただけないでしょうか？ > sf.netからダウンロードしてsupport-files/my-small.cnfほぼそのままな状態です。 とのことですので、たぶんmysql-5.0.45-tritonn-1.0.7のバイナリだと思う のですが、RPM/tarball版、i686/x86_64版の組み合わせで4パタンあります。 (再現させた場合のstacktraceが完全に一致することを確認するためです。） お手数ではありますが、よろしくおねがいいたします。 > > こんばんは、いちいです。 > > > 池田さんにこちらへと言われたので、バグ報告をこちらに投げさせて > いただきます。 > > 長くなっちゃいますけど、エラーログの内容も貼り付けます。 > 報告だけですいません…。 > > > * 内容 > 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 mailing list > Trito****@lists***** > http://lists.sourceforge.jp/mailman/listinfo/tritonn-dev ------------------------------ Tetsuro IKEDA Sumisho Computer Systems, Corp. http://www.scs.co.jp/mysql/ ------------------------------
