いつものことだけども/usr/lkm/compat_linux.oがmodloadできなくなっとる、4.99.25。
あとでちとチェックしとくか。
The Traveling Wilburys Collection
もう長いこと廃盤状態だったとは知らんかったが、リマスタ+DVD付きで再発なのでゲと。
/usr/lkm/compat_linux.o: In function `linux_sys_ptrace':
: undefined reference to `linux_sys_ptrace_arch'
/usr/lkm/compat_linux.o:(.data+0xb88): undefined reference to `linux_sys_futex'
modload: can't prelink `/usr/lkm/compat_linux.o' creating `/usr/lkm/compat_linux'
前者のlinux_sys_ptraceは
kern/34478で報告済のやつ。
linux_sys_futexの方はこんなパッチでおｋ。
Index: sys/compat/linux/common/linux_futex.c
===================================================================
RCS file: /cvsroot/src/sys/compat/linux/common/linux_futex.c,v
retrieving revision 1.7
diff -u -r1.7 linux_futex.c
--- sys/compat/linux/common/linux_futex.c 24 Jul 2006 19:01:49 -0000 1.7
+++ sys/compat/linux/common/linux_futex.c 7 Aug 2007 02:04:22 -0000
@@ -34,6 +34,8 @@
#include <sys/cdefs.h>
__KERNEL_RCSID(1, "$NetBSD: linux_futex.c,v 1.7 2006/07/24 19:01:49 manu Exp $");
+#include <sys/param.h>
+#include <sys/kernel.h>
#include <sys/types.h>
#include <sys/time.h>
#include <sys/systm.h>
@@ -43,6 +45,8 @@
#include <sys/lock.h>
#include <sys/malloc.h>
+#include <compat/linux/common/linux_types.h>
+#include <compat/linux/common/linux_signal.h>
#include <compat/linux/common/linux_futex.h>
#include <compat/linux/linux_syscallargs.h>
Index: sys/lkm/compat/linux/Makefile
===================================================================
RCS file: /cvsroot/src/sys/lkm/compat/linux/Makefile,v
retrieving revision 1.32
diff -u -r1.32 Makefile
--- sys/lkm/compat/linux/Makefile 22 Apr 2007 08:30:01 -0000 1.32
+++ sys/lkm/compat/linux/Makefile 7 Aug 2007 02:04:22 -0000
@@ -22,6 +22,7 @@
SRCS+= linux_machdep.c linux_syscalls.c linux_sysent.c
SRCS+= linux_fdio.c linux_hdio.c linux_blkio.c linux_sysctl.c
SRCS+= linux_sg.c linux_mtio.c
+SRCS+= linux_ptrace.c linux_futex.c
# XXXX - temporary, not applicable for kernel with COMPAT_43, OSSAUDIO
#.PATH: $S/compat/common $S/compat/ossaudio
それと kern/34010は最近直っとるな、closeしとくか。
src/libexec/rtld-elf/rtld.h rev1.38
93 typedef struct Struct_Name_Entry {
94 STAILQ_ENTRY(Struct_Name_Entry) link;
95 char name[1];
96 } Name_Entry;
src/libexec/rtld-elf/rtld.c rev1.124
3144 static void
3145 object_add_name(Obj_Entry *obj, const char *name)
3146 {
3147 Name_Entry *entry;
3148 size_t len;
3149
3150 len = strlen(name);
3151 entry = malloc(sizeof(Name_Entry) + len);
3152
3153 if (entry != NULL) {
3154 strcpy(entry->name, name);
3155 STAILQ_INSERT_TAIL(&obj->names, entry, link);
3156 }
3157 }
3151行目の + len を見てなくてオーバーフロー疑っちまったぜ。
これはstrdup(3)とか使わずにmalloc(3)一回で済ませて性能を稼ぐ意図なのかねぇ。
リンクローダってそんな切羽詰った実装しないとダメなのかな？
なぜOpenBSDのCitrusは完全体でないのか(フリーザ様AA略
http://www.undeadly.org/cgi?action=article&sid=20070806022021&pid=41
Theoにとっての
夏蜜柑が四つPlain Citrusにあるいくつかの問題ってなんだろうね、やっぱdlopen(3)かねぇ。
もしかしてBSD AUTHみたくmultibyte encoding moduleをshared libraryでなくexecutableにすりゃ
納得するんだろうかｗｗｗｗｗちょｗｗ無意味ｗｗｗｗ
奥多摩行ってきた。
天気は最高だったんだけども
夏休み中ということで子供連れ家族で大渋滞、時間おせおせ。
バーベキューも日が暮れかかってから大急ぎになってしまった、あーあ。
桧原村まで行って数馬の湯に浸かって、その後ペルセウス流星群を見る予定だったのが
奥多摩周遊道路の19:00-8:00通行止に10分の差で引っかかってしまい断念、もえぎの湯に変更。
狭いし混んでるしお湯ぬるぽでいまいちだった。
リハビリがてらn-byte hangulのモジュール書いた、週末時間あればcommitすんべ。
雑巾風味のコーヒーと猫もまたぐ腐臭ツナパスタにやられて寝込んでた。
しばらく会社のtrac鯖放置してたので更新した。
LC_TIMEがUTF-8ロケールでない場合
バグ対策パッチがあたらなくなってたので更新。
/distfiles/trac/trac-0.10.4-strftime_use_nl_langinfo_codeset.patch.gz
あ、ちなみにtrac-jaの方はstrftime/strptimeに喰わせるformat自体を
無理矢理'%x %X'でなく'%Y/%m/%d %H:%M:%S'に変えてしまうとゆー
adhocでkludgeな対策してるみたいなんで上のpatchはrejectでます。
ついでにFC6からFC7に更新、近いうちにSuSEに入れ換える。
$ fc-match serif
VeraSe.ttf: "Bitstream Vera Serif" "Roman"
$ LC_CTYPE=ja_JP.eucJP fc-match serif
12x13ja.pcf.gz: "Fixed" "ja"
STARTFONT 2.1
COMMENT JIS X208 glyphs donated by T.Maebashi <maebashi@mcs.meitetsu.co.jp>
COMMENT Adapted and extended for ISO 10646-1 by Markus Kuhn <mkuhn@acm.org>
COMMENT This font was scaled down from a 14x14 source font
COMMENT Hangul glyphs prepared by Won-kyu Park <wkpark@chem.skku.ac.kr>
COMMENT from BAEKMUK font.
COMMENT Id: 12x13ja.bdf,v 1.23 2000-12-07 21:56:41+00 mgk25 Exp mgk25 $
FONT -Misc-Fixed-Medium-R-Normal-ja-13-120-75-75-C-120-ISO10646-1
* {
font-family: Gothic !important;
}
$ LC_CTYPE=ja_JP.eucJP /usr/pkg/bin/fc-match gothic
monau12.pcf.gz: "Gothic" "Regular"
$ /usr/pkg/bin/fc-list | grep Gothic
Gothic:style=Bold
Gothic:style=Italic
...
$ LC_CTYPE=ja_JP.eucJP /emul/linux/usr/bin/fc-match gothic
12x13ja.pcf.hz: "Fixed" "ja"
$ /emul/linux/usr/bin/fc-list | grep Gothic
Mona Gothic:style=Regular
Mona Gothic Wide:style=Italic
...
tech-userlevelネタ。
wizd(8)氏の添付したmp3ファイル(のようなもの)じゃde_DE.UTF-8ロケールでも再現しないねぇ。
ソース。
143 r = mbrtowc(wc, p, mblen, st);
144 if (r == (size_t)-1) {
145 warnx("%s: invalid byte sequence", file);
146 rval = 1;
147
148 /* XXX skip 1 byte */
149 mblen--;
150 p++;
151 memset(st, 0, sizeof(*st));
152 continue;
153 } else if (r == (size_t)-2)
154 break;
155 else if (r == 0)
156 r = 1;
そもそも*.mp3のよなバイナリをUTF-8だとしてmbrtowc(3)に喰わせれば
EILSEQになる可能性は高い、wc -cを使いましょうってことで。
↑の問題とは関係ないんだけど、今の実装だとmbrtowc(3)の使い方がちとマズイ。
注目は155～156行目、mbrtowc(3)の
仕様書には「戻り値として0が返ってきた場合
変換結果はnullワイド文字になる」と書いてある。
RETURN
0
If the next n or fewer bytes complete the character that corresponds
to the null wide character (which is the value stored).
なので
のはとても正しいように思えるんだけど、実際には
*wc == L'\0' の場合、 r == (size_t)0 は「真」は正しいんだけれども、その逆は真ならずなのよね。
155 else if (*wc == L'\0')
L'あ' → { 0x1b, '$', 'B', '$', '"' }
L'\0' → { 0x1b, '(', 'B', '\0' }
となり、G0をasciiに切り替える為のescape sequenceが必要になる場合もあるわけ。
r = mbrtowc(wc, p, 1, st); /* mblen分食わせるのでなく、1byteづつに制限する */
if (r == (size_t)-1) {
...
} else if (r == (size_t)-2)
break;
mblen--;
p++;
r = mbrtowc(wc, p, mblen, st);
if (r == (size_t)-1) {
...
} else if (r == (size_t)-2)
break;
else if (*wc == L'\0') {
while (*p) {
p++;
mblen--;
}
r = 1;
}
...
mblen -= r;
p += r;
もいっこバグ見つけた。
206 while ((len = read(fd, buf, MAXBSIZE)) > 0) {
207 if (dochar) {
208 size_t wlen;
209
210 r = do_mb(0, (char *)buf, (size_t)len,
211 &st, &wlen, name);
テキストファイルからread(2)で読み込んだバイト列に'\0'つかない時
iconv(1)のISO-2022-JP問題と同様の問題が発生する悪寒、ひー。
さてどうやって修正しますかねぇ…
Citrus API直接呼ぶのもアレなので
285 if (dochar && r == (size_t)-2) {
286 warnx("%s: incomplete multibyte character", name);
を
285 if (dochar && r == (size_t)-2 && !mbsinit(&st)) {
286 warnx("%s: incomplete multibyte character", name);
とかしてmbsinit(3)によるチェックくらいでお茶を濁す？
ここまでの 暫定patch。
まあテキストファイルであれば通常末尾にnewline(0xa)があることが多いんで
これを意図的に除去しない限りは
$ LC_ALL=ja_JP.ISO2022-JP wc -m hoge.txt
wc: hoge.txt: incomplete multibyte character
が発生することはないよなぁ、発生頻度は低そうなのでしばらく放置するかね。
壊れてたみたい、失礼しました。
「お前一日中ヒキってWikipediaの編集合戦ってどんだけよ？」
「あ？ オリャぁアリマキ駆除してんだよ。」
「ってかアリマキって何よ？ アリマキなんか何処にもいないぜ？」
「オメーもそのうち奴らに洗脳されちまうぜ？ それがアリマキさ。
ネットの何処からでも湧いきて、俺の秀逸な記事を削除しようとしやがる。
もう耐えらんねぇ … こっちが病院送りになっちまう。」
「なんでオレにゃ見えねーの？」
「ほれ見ろぉぉぉぉ！このアリマキ cia.gov からだぜぇぇぇぇぇ！」
(以下略)
そしてフレッド潜入捜査官のように自分で自分を(以下略)って話なのか？
というわけで ``A Scanner Darkly'' - Philip K. Dick 苦労しながら原著読んでるんだが
このあたりのシーンの台詞が「シンナーに気をつけて」とか「盗聴エディ」に脳内変換されて非常に困る。