2007年12月11日の日記を表示中
2007年12月11日 (火)
■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の追加を提案するのが上策ですかね・・・.
[コメントを書く]
■アンデフ
懲りずに2面を練習.珍しく100% が取れました.全然うまくなった気しないけど.なかなか参考動画のようにはいきません・・・.
[コメントを書く]
2007年12月11日の日記を表示中
toggle-im の中の im-retrieve-context が原因でしょうか? 1.4 だと、find-context だったので問題なかったんでしょうね。
(゜∀゜)人(゜∀゜)
> あと、uim_switch_im() の encoding 変更可能版が必要ということでしたら、
> bugzilla に書いておきますよ。
おお,じゃあお言葉に甘えて(いいものかという気もしますが・・・)お願いします.
ところで今回のvalgrindのlogはどうやったら引っかかったんでしょうか。最近のtrunkだとSEGVが再現しなくなってて、GCまわりにもおかしいところが見つからないんで旧revisionに戻してテストしなければいかんかなーと思ってたりしましたが。
いやー,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