Tetsuro IKEDA
ikdtt****@gmail*****
2008年 2月 5日 (火) 15:51:10 JST
こんにちは。池田です。 見たところ、tritonn-1.0.7で修正したバグと関連がありそうです。 http://qwik.jp/tritonn/ChangeLog.html#mysql-5_0_45-tritonn-1_0_7 mysql-4.1.22をお使いということで恐縮なのですが、 tritonn-1.0.7以上( with mysql-5.0系）をお試しいただけますでしょうか？ 宜しくお願いいたします。 08/02/05 に 武井宜行<ntake****@sios*****> さんは書きました: > 池田様 > > 武井です。下記のような感じでよろしいでしょうか。 > > 宜しくお願い致します。 > > x8144d83 handle_segfault + 643 > 0x2ba0d1 (?) > 0x836d716 mi_delete_all_rows + 326 > 0x81a5849 _Z12mysql_deleteP3THDP13st_table_listP4ItemP11st_sql_listym + 2057 > 0x815a0ba _Z21mysql_execute_commandP3THD + 2794 > 0x815f695 _Z11mysql_parseP3THDPcj + 373 > 0x815fb38 _Z16dispatch_command19enum_server_commandP3THDPcj + 1096 > 0x81616a9 handle_one_connection + 2153 > 0x4f45c2db _end + 1190049507 > 0x4f3b612e _end + 1189369142 > > > On Mon, 04 Feb 2008 19:25:42 +0900 > Tetsuro IKEDA <te.ik****@jpta*****> wrote: > > > こんにちは。池田と申します。 > > > > 武井さん、バグ報告ありがとうございます。 > > > > エラーログにstacktraceが出ていると思うのですが、 > > お手数ですが下記のページを参考にresolve_stack_dumpを実行した > > 結果を送っていただけませんでしょうか？ > > > > E.1.4. スタックトレースの使用 > > http://dev.mysql.com/doc/refman/4.1/ja/using-stack-trace.html > > > > お手数をおかけして恐縮ですが、よろしくお願いいたします。 > > > > > > > > > はじめまして。武井と申します。 > > > > > > RHEL上にてtritonn-1.0.2、mysql-4.1.22、senna-1.0.4を構築して使用して > > > おります。ソースから特定の操作をしたときに、MySQLが落ちるエラーが > > > 起こります。 > > > > > > 色々な情報をネットで探しましたが、いまだに解決方法がわかりません。 > > > 何卒解決方法をご教示の程宜しくお願いします。 > > > > > > > > > ■発生状況 > > > 1.元のデータをダンプしたファイルの先頭に、ダンプした各テーブルの > > > DELETE文を記述し、下記のようなSQLを書きます。 > > > > > > ----------------- > > > #データ削除SQLの追記 > > > delete from hoge1; > > > delete from hoge2; > > > delete from hoge3; > > > delete from hoge4; > > > delete from hoge5; > > > > > > #ダンプデータの挿入 > > > insert into hoge1('aaa','bbb','ccc','ddd'),('aaa','bbb','ccc','ddd')... > > > insert into hoge2('aaa','bbb','ccc','ddd'),('aaa','bbb','ccc','ddd')... > > > ----------------- > > > > > > 上記のInsert文の1行のサイズは最大342,744byte、SQL文全体でのサイズは > > > 345,890byteです。 > > > > > > > > > 2.上記のようなファイルをmysqlコマンドで実行します。すると下記のような > > > エラーが標準出力に表示され、MySQLが落ちてしまいます。 > > > > > > ERROR 2013 (HY000) at line 1: Lost connection to MySQL server during > > > query > > > > > > そのときmsqlログでは下記のようなログを吐きました。 > > > > > > 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=8388600 > > > read_buffer_size=131072 > > > max_used_connections=2 > > > max_connections=100 > > > threads_connected=2 > > > It is possible that mysqld could use up to > > > key_buffer_size + (read_buffer_size + sort_buffer_size)*max_connections = 225791 K > > > bytes of memory > > > Hope that's ok; if not, decrease some variables in the equation. > > > > > > thd=0xb1c2b00 > > > 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=0x8451d8, backtrace may not be correct. > > > Stack range sanity check OK, backtrace follows: > > > 0x8144d83 > > > 0x2ba0d1 > > > 0x836d716 > > > 0x81a5849 > > > 0x815a0ba > > > 0x815f695 > > > 0x815fb38 > > > 0x81616a9 > > > 0x4f45c2db > > > 0x4f3b612e > > > New value of fp=(nil) failed sanity check, terminating stack trace! > > > 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 0xab2a7a0 = delete from t_pdf_tag > > > thd->thread_id=3 > > > 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. > > > > > > > > > sennaをインストールしないmysql4.1.22では、上記エラーは起こりません。 > > > またdelete文ではなく、truncate文に変更してファイルを実行した場合、 > > > エラーは起こりませんでした。 > > > > > > 以上、宜しくお願い申し上げます。 > > > > > > _______________________________________________ > > > Senna-dev mailing list > > > Senna****@lists***** > > > http://lists.sourceforge.jp/mailman/listinfo/senna-dev > > > バグ報告方法：http://qwik.jp/senna/bug_report.html > > > > ------------------------------ > > Tetsuro IKEDA > > Sumisho Computer Systems, Corp. > > http://www.scs.co.jp/mysql/ > > ------------------------------ > > > > _______________________________________________ > > Senna-dev mailing list > > Senna****@lists***** > > http://lists.sourceforge.jp/mailman/listinfo/senna-dev > > バグ報告方法：http://qwik.jp/senna/bug_report.html > > > ・‥…━━━━━━━━━━━━━━━━━━━━━━━…‥ > サイオステクノロジー株式会社 > Webソリューション部 > ネットデザイングループ > 武井 宜行 > 〒105-0001 東京都港区虎ノ門4-1-28 虎ノ門タワーズ > TEL：03-6860-5127 > FAX：03-6860-5135 > http://www.sios.com/ > ・‥…━━━━━━━━━━━━━━━━━━━━━━━…‥ > > _______________________________________________ > Senna-dev mailing list > Senna****@lists***** > http://lists.sourceforge.jp/mailman/listinfo/senna-dev > バグ報告方法：http://qwik.jp/senna/bug_report.html > -- Tritonn http://qwik.jp/tritonn/ hatena http://d.hatena.ne.jp/mir/ twitter http://twitter.com/_mir_
