Naoya Murakami
visio****@gmail*****
2013年 9月 26日 (木) 08:16:53 JST
お世話になっております。村上です。
すいません。もう一度ソースを見直してみたところ、だめだめな点に気づいたので、
修正したら、これまで、corrupted double-linked listが発生してたところで、
再現しなくなりました。
データベースが大きいので、まだ、全インデックス構築は完了していませんが、
おそらくは、うまくいきそうです（いってほしい）。
この事象は、当方のミスでした。大変失礼しました。
>手元でも試してみたいので、以下の情報を教えてもらえませんか？
> 1. mroongaでのテーブル定義
（どのトークナイザーを使っているかを知りたい）
> 2. エラーが発生したINSERT文
（どのデータで問題なのかを知りたい）
> 3. 1., 2.のgrnntestバージョンの作成
> 4. 3.で問題が再現するかどうかの確認
トークナイザは、TokenMecabStopWordsLengthProlongを使っています。
PartOfSpeechは、速度の劣化が著しいので、とりあえず放置してました。
細かく分割すると、事象が発生せず、ある部分を含んで、且つ、ある一定量のサイズを
オフラインインデックス構築すると事象が発生していました。
なので、特定のINSERT、特定のデータのオフラインインデックス構築だけでは再現せず
厄介でした。
しかし、上記を整理するために、オリジナルのMecabのトークナイザにmecab_sparse_tostrの
分割処理のみだけを追加したものを作っているうちに、だめだめなところが気づきました。
https://github.com/naoa/groonga-tokenizer-customized/blob/master/tokenizers/mecablong.c
ちゃんとgrntestで分割処理を動きを確認することにより、ループの最後の処理がうまく終わってなくて、
複数回、無駄な処理がやられていることに気づけました。
（無駄な分かち書きはされず、うまくいくケースもあったので、前は気づきませんでした。）
https://github.com/naoa/groonga-tokenizer-customized/blob/master/test/suite/mecablong/TokenMecabLong.actual
また、放置していたpartofspeech系の処理で生じていたメモリリークもすぐに確認することができて、
便利でした。
以上、よろしくお願いします。