From: TAKAHASHI T. <ta...@mo...> - 2004-03-20 09:19:42
|
高橋全です。 問題が発生する環境から要素を引いていって発生しなくしましたが 発生しないミニマル環境から問題のある環境を構築してはいなかったので ちょっと変なことを言ってたようです。 以下の 2 ファイルで再現します。(aafont は添付もしてあります) ~/.mlterm/main: use_anti_alias=true not_use_unicode_font=true ~/.mlterm/aafont (in UTF-8): #ISO8859_1=Fモトヤシーダ1等幅-iso8859-1:100 ISO8859_1=Nimbus Mono L-iso10646-1:120 ISO8859_2=Nimbus Mono L-iso10646-1:120 ISO8859_9=Nimbus Mono L-iso10646-1:120 ISO8859_10=Nimbus Mono L-iso10646-1:120 ISO8859_11=Nimbus Mono L-iso10646-1:120 ISO8859_13=Nimbus Mono L-iso10646-1:120 ISO8859_15=Nimbus Mono L-iso10646-1:120 US_ASCII=Fモトヤシーダ1等幅-iso10646-1:100 DEC_SPECIAL=Fモトヤシーダ1等幅-iso10646-1:100 KOI8_R=Nimbus Mono L-iso10646-1:50; JISX0201_ROMAN=Fモトヤシーダ1等幅-iso10646-1:100 JISX0201_KATA=Fモトヤシーダ1等幅-iso10646-1:100 JISX0208_1978=Fモトヤシーダ1等幅-iso10646-1:100 JISX0208_1983=Fモトヤシーダ1等幅-iso10646-1:100 JISX0208_1990=Fモトヤシーダ1等幅-iso10646-1:100 KSX1001_1997=Baekmuk Dotum-iso10646-1:100 aafont からどのエントリを消すと解決するか、は何種類もありました。 必ずしも ISO8859_x が悪いわけではないようでした。 UTF-8 半角カナ (というのが本当にあるのか知りませんが モトヤシーダを fc-cache して fc-list すると出てくる文字です) が本当の原因かもしれません。 JISX... を全部消しても解決しますし KSX... を消しても、ちゃんと終了するようになりました。 ただ、KSX... を消しただけだと、mlterm --daemon=blend と mlclient --aa=false を上げた状態で mlterm の方を exit すると mlclient も死にました。もうよく分かりません。 On Sat, Mar 20, 2004 at 02:19:09AM +0900, Seiichi SATO wrote: > > ~/.mlterm/aafont に不適切な ISO8859_x エントリが > > あると、(たとえば > > ISO8859_9=Nimbus Mono L-iso10646-1:120 > > ISO8859_10=Nimbus Mono L-iso10646-1:120 > > ISO8859_13=Nimbus Mono L-iso10646-1:120 > > ISO8859_15=Nimbus Mono L-iso10646-1:120 > > 等がどれが一つでもあると、) > > 不適切というのは行末に ';' がないという意味でしょうか? > それとも存在しないフォントを指定した場合という意味でしょうか? ISO-8859-x を持たないフォントを指定した場合、 という意味のつもりでした。その根拠は、 「ISO-8859-1 には ';' を付けなくても使えたから」です。 しかし、両方とも関係あるのかもしれません。 On Fri, Mar 19, 2004 at 09:04:05PM +0900, MINAMI Hirokazu wrote: > > ~/.mlterm/aafont に不適切な ISO8859_x エントリが > > あると、 > ... > > daemon=blend のときにすべてプロセスを終了しようとしても > > 画面に現れないプロセスが終了せずに CPU を食っていたり、 > > それを無理矢理殺すと環境変数らしき文字列を吐いたり > > するようです。 > > 手元では再現できなかったので、終了しなくなった時点での > スタックトレースを見せていただけるとありがたいです。 > > # 「gdb /usr/bin/mlterm [プロセスID] して bt」 とかで > # とれるでしょうか。 そうすると malloc_consolidate (av=0x4057b5c0) at malloc.c:4368 4368 malloc.c: そのようなファイルやディレクトリはありません. in malloc.c (gdb) bt #0 malloc_consolidate (av=0x4057b5c0) at malloc.c:4368 #1 0x404c7f90 in _int_free (av=0x4057b5c0, mem=0x80eaf10) at malloc.c:4260 #2 0x404c6d88 in __libc_free (mem=0x80e3b10) at malloc.c:3359 (gdb) となります。mlterm とは関係がないということでしょうか? それとももっと深いデバグ方法が必要なだけ? すみません変な報告で。 -- tamo |