Kazuki Ohta
mover****@hct*****
2005年 1月 2日 (日) 09:42:23 JST
太田です。 uim svn r90 ./configure --enable-scm-nested-eval --disable-callback-queue --enable-debug の環境にupdateした所、mlterm ( http://mlterm.sourceforge.net/, 2.9.1, build from source code ) が下のようなbacktraceを吐いて落ちるようになってしまいました。 $mlterm --im=uim キーを押すと即座にクラッシュします。 * gdbで取ったbacktrace #0 0x4108eb9f in strlen () from /lib/libc.so.6 (gdb) bt #0 0x4108eb9f in strlen () from /lib/libc.so.6 #1 0x402b98e8 in prop_label_update (p=0x0, str=0x0) at im_uim.c:439 #2 0x402c5b41 in im_update_prop_label (id=0x40618758, prop_=0x40634da8) at uim-func.c:611 #3 0x402ccb16 in leval (x=0x40348be8, env=0x40634d78) at slib.c:2769 #4 0x402cdd38 in leval_progn (pform=0xbfffee60, penv=0xbfffee64) at slib.c:3084 #5 0x402ccee6 in leval (x=0x403492f8, env=0x406331e8) at slib.c:2819 #6 0x402cdd38 in leval_progn (pform=0xbfffef00, penv=0xbfffef04) at slib.c:3084 #7 0x402ccee6 in leval (x=0x405fe508, env=0x40625ce8) at slib.c:2819 #8 0x402c805e in repl (h=0xbfffefb0) at slib.c:561 #9 0x402c88c1 in repl_driver (want_init=0, h=0xbfffefb0) at slib.c:799 #10 0x402c9732 in repl_c_string (str=0x81489f8 "(key-press-handler 0 97 0)", want_init=0, want_print=1) at slib.c:1274 #11 0x402c549f in uim_eval_string (uc=0x817acf8, buf=0x81489f8 "(key-press-handler 0 97 0)") at uim-func.c:361 バグ報告でしたm(_ _)m > custom APIの改訂に伴ってuim-scm APIも位置付けが変わりつつあるの > で最近の変化を紹介しておきます。 > > 現在のlibuimはSchemeインタプリタのsiodをuim向けに改変したものに > べったり依存する形で書かれているんですが、これを整理してuim-scm > APIによってSchemeインタプリタを抽象化し、直接siodの関数を呼ぶ代 > わりにuim_scm_*()を介して呼び出すように変えつつあります。siodが > 公開しているシンボルは他のライブラリ等と衝突しやすい短かい名前な > のでuim_scm_プリフィクスを付けてそれを回避する目的もあります。 > > これはlibuim内部利用の他、IMプラグイン内でCからSchemeインタプリ > タにアクセスする際にも使われる事を意図しています。以前のuim-scm > APIはGCまわりのハンドリングがまずかったため実用になりませんでし > たが、後述の改変によりある程度安全に利用できるようになっています。 > スタック上のlispオブジェクト保護のためにはちょっと特殊な作法が必 > 要なのでドキュメントが必要ですが。 > > libuimとSchemeインタプリタ間のインタフェイスが十分細くなって抽象 > 化された時点でTinySchemeやGaucheに挿し替えられるようにしたいと思っ > ています。siodは標準仕様に沿っていない、ライブラリが少ない等の問 > 題があるので。また、Gaucheのような大きめの実装は十分なリソースの > 用意できない環境では利用しにくいのでそのままでは標準にはできない > と思いますが、リッチなプログラミング環境を生かしてのプロトタイピ > ングには有用だと思います。 > > uim/uim-scm.c: > #if 0 > /* > To avoid namespace pollution, all siod functions should be static > and wrapped into uim-scm.c by direct inclusion rather than linked > via public symbols. After uim_scm_* abstraction, the Scheme > interpreter implementation can be switched to another one such as > uim-scm-tinyscheme.c or uim-scm-gauche.c. But uim/*.[hc] and > scm/*.scm are still depending on siod in several ways. At least full > test suite for *.scm files are required to migrate to another Scheme > implementation. -- YamaKen 2004-12-21 > */ > #include "slib.c" > #endif > > > At Sun, 03 Oct 2004 18:35:45 +0900, > > yamak****@bp***** wrote: > > Schemeの実装の話になったのでついでに触れておきますが、現在のsiod > > では repl_c_string() → callback → repl_c_string() のようにnest > > した形でrepl_c_string()を呼ぶとGCがおかしくなるため、uimでは > > callback queueを使ってこれを回避していますが、repl_c_string()の > > 内部で呼ばれているrepl_driver()の実装をいじって、stack_start_ptr > > の初期化を最初のrepl_c_string()呼び出し時に限って行う事でこの問 > > 題を回避できるんじゃないかと考えています。実際の検証はまだですが、 > > repl_c_string()がnested reentrantだとAPIの設計自由度が増すので、 > > uim-scm API(とcustom API)の改訂時に実験してみようと思っています。 > > これもr86, r88, r89で対応し、一応の正常動作を確認しました。 > > 今まではこの制限のためSchemeからcallback関数を呼んだり、Cの呼び > 出し側スタック上にlispオブジェクトを置いたりする事が自由にできな > かったんですが、両方とも可能になったので今後はそれを前提にlibuim > 内部を柔軟でシンプルな形に再編・拡張してゆくつもりです。 > > 手始めにcustom APIの「あるcustom variableが更新された時に呼ばれ > るC callback」を実現するために利用します。これは現在のcallback > queueでは実現できないため、callback queueの廃止が前提です。廃止 > のスケジュールは以下のように予定していますが、何か関連する作業を > 行っていたり問題を感じている方は意見ください。 > > 0.4.6リリースまでの間、なるべく以下のコンフィギュレーションでテ > ストして頂けると助かります。もしバグがあった場合にはアプリごとク > ラッシュしますのでご注意ください。もちろん問題無い事を期待してい > ますが。 > > configure --enable-scm-nested-eval --disable-callback-queue > > ------------------------------------------------------------------------ > r86 | yamaken | 2004-12-31 05:41:21 +0900 (Fri, 31 Dec 2004) | 30 lines > > * This commit adds nested Scheme evaluation feature described > below. The feature will be enabled by default once tested enough. > - nested Scheme evaluation from C (i.e. C -> Scheme -> C -> Scheme) > - protect lisp objects on the caller stack from GC > > ------------------------------------------------------------------------ > r89 | yamaken | 2004-12-31 07:32:55 +0900 (Fri, 31 Dec 2004) | 49 lines > > * This commit removes callback queue from libuim to simplify the > internal implementation. Whether use the callback queue or not is > still configurable at compile time: > > - The old code using callback queue > > configure --disable-scm-nested-eval --enable-callback-queue > > - The new simplified code without callback queue > > configure --enable-scm-nested-eval --disable-callback-queue > > - The new simplified code without callback queue, but sometime > crashes the application process. Exist only for testing purpose > > configure --disable-scm-nested-eval --disable-callback-queue > > Please test the second configuration. The second will be default for > uim 0.4.6 if no fatal behavior is reported. After 0.4.6, the old > codes enclosed by #ifdef UIM_CALLBACK_QUEUE will be removed to > prepare further libuim simplification. If the callback queue is > completely gone, we can simplify other codes affected by the > callback queue such as uim_eval_string() > > ------------------------------- > ヤマケン yamak****@bp***** > _______________________________________________ > Anthy-dev mailing list > Anthy****@lists***** > http://lists.sourceforge.jp/mailman/listinfo/anthy-dev -- --------------------------------- Move the worl:D! Kazuki Ohta : mover****@hct*****
