2007年12月11日の日記の1番目の記事へのコメント

uim.el

朝,パンをかじりつつ (引っ越してからパン食派になってしまった) 昨日書いた,uim.el のREADME.ja をどうしようとかいうエントリを読み返していたら,ふとヤマケンさんのメールを思い出し,試しに valgrind を走らせてみたところ・・・

==11220== Invalid read of size 4
==11220==    at 0x4050D31: im_retrieve_context (uim-func.c:74)
==11220==    by 0x402C4CA: call (eval.c:415)
==11220==    by 0x402C784: scm_eval (eval.c:499)
==11220==    by 0x402DD16: scm_s_let_internal (syntax.c:558)
==11220==    by 0x402DBB4: scm_s_let (syntax.c:496)
==11220==    by 0x402C505: call (eval.c:420)
==11220==    by 0x402C784: scm_eval (eval.c:499)
==11220==    by 0x402E957: scm_s_begin (syntax.c:830)
==11220==    by 0x402E81D: scm_s_body (syntax.c:799)
==11220==    by 0x402E10B: scm_s_letstar (syntax.c:621)
==11220==    by 0x402C505: call (eval.c:420)
==11220==    by 0x402C784: scm_eval (eval.c:499)
==11220==  Address 0x46552A0 is 0 bytes inside a block of size 108 free'd
==11220==    at 0x40220DA: free (vg_replace_malloc.c:233)
==11220==    by 0x404F2FC: uim_release_context (uim.c:241)
==11220==    by 0x804A9B5: update_context_encoding (context.c:72)
==11220==    by 0x804B193: update_context_configuration (context.c:400)
==11220==    by 0x804D7B9: configuration_changed_cb (callback.c:154)
==11220==    by 0x40516BB: raise_configuration_change (uim-func.c:400)
==11220==    by 0x402C4CA: call (eval.c:415)
==11220==    by 0x402C784: scm_eval (eval.c:499)
==11220==    by 0x402E957: scm_s_begin (syntax.c:830)
==11220==    by 0x402E81D: scm_s_body (syntax.c:799)
==11220==    by 0x402E10B: scm_s_letstar (syntax.c:621)
==11220==    by 0x402C505: call (eval.c:420)

こ,これは・・・(;´Д`) ・・・そんなわけで,たまたま目についた update_context_encoding を外してみたら落ちなくなったというだけの話でした.im_retrieve_context の中で読もうとしている領域が,uim_release_context によって既に解放されちゃっているのが問題なんすかね・・・.うーん.

何でここでコンテキストを解放しているのかというと,uim-el-agent は,Emacs的な事情から,Anthyのときは EUC-JPで,Byeoruのときは EUC-KR でといった風に,言語に合わせてuim側の出力のエンコーディングを変えなければならず,UTF-8で一本化ができないんですよね.が,uimは,確か一度コンテキストを作ると,そのコンテキストのエンコーディングを変えることができないので,uim.el では,異なる言語のIMに変更になってエンコーディングを変える必要が生じた際には,一旦古いコンテキストを捨てて,新しくコンテキストを作り直すといったことをやっている・・・はずだったと思います (何か前にもこんなことを書いて佐藤さんか誰かにつっこまれたような・・・)

・・・あれ? そういえば configuration_changed_cb は uim_context のメンバなんだよなー. ということは,これを呼んだ先で,呼び元のコンテキスト解放してるってこと・・・? configuration_changed_cb から戻った後,uim_scm_t から返った後に何が起きてるのかよくわかんないんですが,さすがにこれはヤバいんじゃ・・・.

というわけで,試しに uim-internal.h を emacs/context.c から include して,コンテキストの中身を直接いじってみたら,AnthyとByeoruの間で切り替えまくってもまったく落ちなくなりました.うわー,ヤマケンさんごめんなさい _|‾|○

Index: context.c
===================================================================
--- context.c   (リビジョン 5054)
+++ context.c   (作業コピー)
@@ -69,10 +69,11 @@
   /* discard current context */
   clear_candidate(ua->cand);
   clear_preedit(ua->pe);
-  uim_release_context(ua->context);
-
-  ua->context = create_context(ua->encoding, ua);

+  if (ua->context->client_encoding)
+      free(ua->context->client_encoding);
+  ua->context->client_encoding = uim_strdup(ua->encoding);
+
   update_context_im(ua);

 }
Index: context.h
===================================================================
--- context.h   (リビジョン 5054)
+++ context.h   (作業コピー)
@@ -43,6 +43,7 @@

 #include <uim/uim.h>
 #include <uim/uim-im-switcher.h>
+#include <uim/uim-internal.h>

 #include "debug.h"
 #include "uim-el-types.h"

APIの追加を提案するのが上策ですかね・・・.

[コメントを書く]

ekato 2007/12/12(水) 15:39:09
ということは、trunk の uim-xim も、EUC-JP のクライアント上で anthy と byeoru の切り替えを試みると落ちますね、というか落ちました…
toggle-im の中の im-retrieve-context が原因でしょうか? 1.4 だと、find-context だったので問題なかったんでしょうね。
ekato 2007/12/12(水) 16:34:55
あと、uim_switch_im() の encoding 変更可能版が必要ということでしたら、bugzilla に書いておきますよ。
nosuke 2007/12/12(水) 20:47:09
> というか落ちました…
(゜∀゜)人(゜∀゜)

> あと、uim_switch_im() の encoding 変更可能版が必要ということでしたら、
> bugzilla に書いておきますよ。
おお,じゃあお言葉に甘えて(いいものかという気もしますが・・・)お願いします.
ヤマケン 2007/12/13(木) 01:42:40
今忘年会帰りで酔っぱらってて頭が回らないんですが、im-retrieve-contextまわりで何か私がやらかしてしまったのは把握しました。軽率ですいませんです。API変更も必要なだけやっちゃう方向でいきましょう。uim 1.5のリリースどこまで延びるんだよという話ですが、もういろいろとgdgdですんで。重ね重ねすいません。

ところで今回のvalgrindのlogはどうやったら引っかかったんでしょうか。最近のtrunkだとSEGVが再現しなくなってて、GCまわりにもおかしいところが見つからないんで旧revisionに戻してテストしなければいかんかなーと思ってたりしましたが。
nosuke 2007/12/14(金) 00:27:27
> uim 1.5のリリースどこまで延びるんだよという話ですが
いやー,uim.elのセグる問題解決マダァ〜(・∀・ )っ/凵 ⌒☆チンチン だと思ってまして,密かに焦ってましたw.README改訂も全然進んでないですし・・・すまんこってす.

> ところで今回のvalgrindのlogはどうやったら引っかかったんでしょうか。
えっと,別に特別なことはせずに,インストールしたやつに対して
valgrind --leak-check=full uim-el-agent
とやったり,kzkさんのページを参考に,makeしたディレクトリで
libtool --mode=execute valgrind emacs/uim-el-agent
とやって起動したりして,
1 1 NEW EUC-JP
1 1 [f7]
で出ました (F7はIMの切り替えに割り当て).
uimの--enable-debug はあってもなくても出たと思います.
LIBUIM_VERBOSEなどは特に設定していません.

valgrindかますと,1 1 [f7]の後も,そのまま落ちずにガシガシ進んでくれるので最初気づかず見落としてたんですが,よく見たらずっとByeoruのままで,変だと思って見返してみたら上記のログが出ていた,という感じです.

検証環境は以下のとおりです.相変わらず変な環境ですが.
- Linux kernel-2.6.22.12 (gcc 3.4.6でコンパイル)
- glibc 2.4 (gcc 3.4.6でコンパイル)
- gcc 4.1.2
- uim trunk-5052 (最適化フラグ指定なし (-O2))
- valgrind 3.2.3
- uim のIM設定 メイン: Anthy (9100d) ・ サブ: Byeoru

お名前:  メールアドレス(省略可):
メールアドレスも表示されます
ここに名前その他を書いてはいけません: ここにメールアドレスその他を書いてはいけません:

2007年12月11日の日記の1番目の記事へのコメント

中の人情報

名前:
nosuke (のすけ)
メール:
sasugaanijaのgmail.com
「の」は「@」みたいな
関連リンク:

カレンダー

2007年12月
            1
2 3 4 5 6 7 8
9 10 11 12 13 14 15
16 17 18 19 20 21 22
23 24 25 26 27 28 29
30 31          

<<先月分

翌月分>>

最新の10件のエントリ

最近の10件のコメント

過去ログ