[go: up one dir, main page]
More Web Proxy on the site http://driver.im/
トップ «前の日記(2012-10-27) 最新 次の日記(2012-10-29)» 編集

日々の破片

著作一覧

2012-10-28

_ 能楽堂 1.3.3

ベースをruby-1.9.3-p286、rails-3.2.8に更新した能楽堂 1.3.3をリリースしました。

このリリースから、須藤さんが(追記:ご免、よく分からない。森さんかも。中田さんも関係してたような)開発されたgroongaという全文検索エンジンと、Railsから利用するためのgem(rroonga)を同梱しています。チュートリアルはgroonga v2.0.7ドキュメント » 4をどうぞ。

なお、起動していきなりgroongaが例外を起こして死ぬ場合は、roaming/nougakudo/bin/readline.dll をリネームしてロードされないようにしてください。

(追記:注意:readline.dllの問題だと思いましたが、違いました。64ビットCLでの最適化に関する問題をGroongaが持っているように見えるため(デバッグモードではまっとうに動作するが、リリースモードでは動いたり死んだりする=初期化に関する何かの最適化によって未初期化メモリを見に行っていると推測できる)、調査してみます。起動できるのであれば、チュートリアルを読みながら試すと良いと思います)

また、演能に修正が入っています。概要はChangeLogにありますが、一番大きいのは近永さんがパッチをくださった、GCなどで通知されるシグナルによって突然プロセスが死ぬ現象に対する修正です。

バンドルされている各種gem(もちろんrailsを含む)やライブラリの開発者各位に感謝します。

_ mallocにでっかな値を与えるとSEGVする?

groonga.exe の 0x000007fcf4c147a3 (ntdll.dll) でハンドルされていない例外が発生しました: 0xC0000005: 場所 0x0000000000dc6b3f を読み込み中にアクセス違反が発生しました。
呼び出しを見ると、
ctx.c 2146行目 grn_malloc_default
size 0x000007fcce93e680 ← mallocのアドレスが0x000007fcce930a36 なので非常に不可思議な値
hash.c 513行目 grn_array_create
path 0x0000000000d0fc39 ← NULLじゃないよ
value_size 0xce9381c8 ← uint32_t だが でかい
flags 0xfffeffff ← くさい
ctx.c 446行目 grn_ctx_impl_init
 見た目、grn_array_createの呼び出しはおかしくない
というわけで、ctx.cが参照しているgrn_array_createの関数プロトタイプが正しく64ビットになっていないように見える。
というところまで調べて昼飯だ。
というか、関数プロトタイプがヘッダに無いように見える。LLP64だから、sizeof(long) != sizeof(void*) に引っかかってるのではないか、と推測できるぞ。
と考えたが、それにしては動くときはちゃんと動くので不思議なので、もっとまじめに見てみるか(groonga.pdbがexeとdllで競合しているから違うものを見ているのかも知れないと気付いた)。
引数がほとんどレジスタに乗っているから、デバッガの変数情報がまったく当てにならない、と気づいた。

_ 上のやつのやり直し

RelWithDebInfoでシンボル情報を取り出して、groonga.dllのほうのpdbを載せて実行してみた。やはり死んだり、うまく動いたりでいろいろ(でたらめな引数を指定してhelp表示で終了するときも、稀に再現するが、最後に死んだ場合はデバッガ起動のフックは外れているらしく捕捉できない)。

再現可能なパターンでのメッセージ(visual studio 2012を使った。2010はうまく情報を取り出せないようだ。でもコンパイルとPDBの作成は2010で行っている)

ハンドルされない例外が 0x000007FCF4C9A485 (ntdll.dll) で発生しました(groonga.exe 内): 0xC0000374: ヒープは壊れています。 (パラメーター: 0x000007FCF4CEFD60)。

壊れているのがヒープならスタックは大丈夫だろうということで、呼び出し履歴を見ると

 	ntdll.dll!RtlReportCriticalFailure()	不明
 	ntdll.dll!RtlpLogHeapFailure()	不明
 	ntdll.dll!RtlpAllocateHeap()	不明
 	ntdll.dll!RtlAllocateHeap()	不明
 	msvcr100.dll!malloc(unsigned __int64 size=0x00000000000002f8) 行 89	C
>	groonga.dll!grn_malloc_default(_grn_ctx * ctx=0x000007fcd3a51000, unsigned __int64 size=0x000007fcd3a1e680, const char * file=0x0000000000000001, int line=0x00000001, const char * func=0x000007fcd3a1e680) 行 2146	C
 	groonga.dll!grn_array_create(_grn_ctx * ctx=0x000007fcd3a51000, const char * path=0x0000000000e8fa49, unsigned int value_size=0xd3a181c8, unsigned int flags=0xfffeffff) 行 513	C
 	groonga.dll!grn_ctx_impl_init(_grn_ctx * ctx=0x0000000000000000) 行 446	C
 	groonga.dll!grn_init() 行 884	C
 	groonga.exe!000007f681e26936()	不明
 	groonga.exe!000007f681e270d2()	不明
 	kernel32.dll!BaseThreadInitThunk()	不明
 	ntdll.dll!RtlUserThreadStart()	不明
 (スタック上の変数値は信用できない。表示されているのはレジスタの値ではない。逆に、スタックを経由しているらしき、msvcr100.dll!mallocに対する引数値(0x0-02f8)は信用できる)

となっていて、mallocより下で発生している。

というのをredmineに投げればいいかな?

本日のツッコミ(全10件) [ツッコミを入れる]
_ kou (2012-10-28 09:02)

ありがとうございます!<br>(groongaのメインの開発者は森さんで、コアの部分とか多くの部分は森さんが書いたものです。私も開発に参加していて、コアの部分よりもユーザーに見えそうな部分の方を書いています。)

_ kou (2012-10-28 13:35)

grn_array_createのプロトタイプはinclude/groonga.hにあるんです。<br>https://github.com/groonga/groonga/blob/master/include/groonga.h#L2730<br><br>プロトタイプの方だとunsinged intと書いていて、定義の方だとuint32_tと書いているのですが、これって問題ありそうでしょうか。。。(理由はgroonga.hをincludeする人はuint32_tを知らなくてもincludeできるようにしたいから。)

_ arton (2012-10-28 14:33)

すみません、後ろに書いてありますが、VSのデバッガは単に関数プロトタイプを見てスタックから変数を表示しているので(というように見える)、最適化してレジスタにパラメータが乗っている場合はでたらめな値が表示されるので勘違いしました。(関数プロトタイプ違いなら、デバッグ版でコンパイルしても同じくエラーになると思う)<br>少なくとも、例外発生時のメッセージからは、mallocの中でヒープの破壊を検出した、ということらしいです。(検出できればそういうエラーになるし、できないと飛んでもないところへ飛んでいって死ぬ、という感じだけど、確証が取れていないです)

_ nagachika (2012-10-29 21:01)

ennou の変更取り込みとリリースありがとうございます!<br>が、NougakuDo 1.3.3 を動作確認したところ、また ennou が死ぬ現象が再現してしまいました。<br>どうも lib/ruby/{site_ruby,vendor_ruby}/1.9.1/x64-msvcr100 の2箇所に ennno.so が存在していて、タイムスタンプから判断すると vendor_ruby のほうだけ更新されているのですが、site_ruby のほうが優先順位が高いため古い ennou.so をロードしてしまっているのではないかと思います。今 site_ruby の下の ennou.so を削除して追試してみていますが今のところは再現していません。<br>なお、rack/handler/ennoumu.rb も site_ruby と vendor_ruby の両方に存在していて、こちらは site_ruby の下のものが更新されているようでした(つまりこっちは新しいほうが有効になっていました)。

_ arton (2012-10-29 21:57)

すみませんすみません、どうもRuby-1.9.3と言い、パッケージングにミスが目立ちますね。<br>上の方でぐちゃぐちゃ書いているgroongaの修正パッチもできたので、合わせて1.3.4を近日中にリリースします。<br>ご報告ありがとうございます!

_ arton (2012-10-29 22:56)

と、調べてみたら、site_rubyのほうは空でした。<br>nagachikaさんがテストのために、setup.rbでインストールしたものが残っていたということではありませんか? (インストーラは既存のファイルは消さないはずなので)

_ nagachika (2012-10-29 23:53)

あっ、なるほど、上書きインストールしたので古いのが残っていたんですね。大変失礼しました。一度アンインストールして再インストールしてみます。

_ arton (2012-10-30 00:06)

アンインストールしても追加分は削除されないはずです。よろしければ、アンインストール後に、一度、site_rubyのほうを確認するか、ディレクトリごと削除してみてください。よろしくお願いします。

_ nagachika (2012-10-30 09:49)

一度ディレクトリごと削除してインストールしなおしてみたら確かに site_ruby には ennou.so 入っていませんでした。おさわがせしました。ごめんなさいごめんなさい orz

_ arton (2012-10-30 12:40)

いえいえ、ビルドしてパッチのテストしていただいてることを思えば、全然OKですよ。


2003|06|07|08|09|10|11|12|
2004|01|02|03|04|05|06|07|08|09|10|11|12|
2005|01|02|03|04|05|06|07|08|09|10|11|12|
2006|01|02|03|04|05|06|07|08|09|10|11|12|
2007|01|02|03|04|05|06|07|08|09|10|11|12|
2008|01|02|03|04|05|06|07|08|09|10|11|12|
2009|01|02|03|04|05|06|07|08|09|10|11|12|
2010|01|02|03|04|05|06|07|08|09|10|11|12|
2011|01|02|03|04|05|06|07|08|09|10|11|12|
2012|01|02|03|04|05|06|07|08|09|10|11|12|
2013|01|02|03|04|05|06|07|08|09|10|11|12|
2014|01|02|03|04|05|06|07|08|09|10|11|12|
2015|01|02|03|04|05|06|07|08|09|10|11|12|
2016|01|02|03|04|05|06|07|08|09|10|11|12|
2017|01|02|03|04|05|06|07|08|09|10|11|12|
2018|01|02|03|04|05|06|07|08|09|10|11|12|
2019|01|02|03|04|05|06|07|08|09|10|11|12|
2020|01|02|03|04|05|06|07|08|09|10|11|12|
2021|01|02|03|04|05|06|07|08|09|10|11|12|
2022|01|02|03|04|05|06|07|08|09|10|11|12|
2023|01|02|03|04|05|06|07|08|09|10|11|12|
2024|01|02|03|04|05|06|07|08|09|10|11|12|

ジェズイットを見習え