Not only is the Internet dead, it's starting to smell really bad.:2009年02月上旬

2009/02/01(Sun)

今日

さみーっす。

バブル期には丸井で吊るしのスーツ( イタ服な)が20~30万とかザラってじっちゃとばっちゃがいってた。

VMware + NetBSD HEADってXを終了するときやたらと刺さるな。
最近は刺さってもjornalingがあるから再起動すりゃいいやとか深追いせず以下略

opensslの0.9.8iと0.9.8jの区別がつかずしばらく悩んだ、フォント変えよう…

pkgsrc/wip/scimの動作確認をOpenBSDでやろうと思ったものの、gccが3.3.5でぐんにょりしたので
FreeBSDをインスコして環境構築ちゅ、8-CURRENT。
まぁbootstrap-pkgsrc使ってるのでDebian/kFreeBSDならぬNetBSD/kFreeBSD状態だけどね。

gccは4.2.1か。

$ gcc -v           
Using built-in specs.
Target: i386-undermydesk-freebsd
Configured with: FreeBSD/i386 system compiler
Thread model: posix
gcc version 4.2.1 20070719  [FreeBSD]

undermydeskって何よと思ってググったけど、 どこで笑えばいいのかよーわからん。
誰かLC_JOKEを実装してくれ。

pkgsrc/lang/perlのpatches/patch-coが8-CURRENTを想定してないのと
pkgsrc/x11/xf86-video-radeonhdで、rhd_helper.cがdefine SEGV_ON_ASSERT 1の場合kill(2)呼ぶのに
sys/types.hとsignal.hをincludeしてるのだけど、これがxf86_ansic.hとconflictしてbuildがコケる。
pkgsrc/devel/nbitoolでFreeBSD.cfのExtraLibariesに-lxpg4(テラナツカシス)があるけど8-CURRENTには以下略。
pkgsrc/inputmethods/canna-libが変、まずpost-configureのsymlinkでコケる、${WRKSRC}/includeがmkdirされてない。
次にnbitoolのxmkmfが走ってないようで、cannot open Makefileとなる、これはX11_TYPE=modularのせい?
あとMakefileの${OPSYS} == "DragonFlyBSD"と同様の処理も以下略。
ちゅーことでscim-cannaやめてscim-anthyでテスト。

結論としてはFreeBSDでも同じように落ちた、char_traitsだけでなくallocatorも書かんといかんのかな。

Program received signal SIGABRT, Aborted.
[Switching to Thread 28c01140 (LWP 100111)]
0x28895af7 in kill () from /lib/libc.so.7
(gdb) bt
#0  0x28895af7 in kill () from /lib/libc.so.7
#1  0x28895a56 in raise () from /lib/libc.so.7
#2  0x2889467a in abort () from /lib/libc.so.7
#3  0x2887a9a6 in __assert () from /lib/libc.so.7
#4  0x2881cca5 in malloc_usable_size () from /lib/libc.so.7
#5  0x2881d227 in free () from /lib/libc.so.7
#6  0x29108ec1 in operator delete () from /usr/lib/libstdc++.so.6
#7  0x28f8998d in std::basic_string<unsigned int, std::char_traits<unsigned int>
, std::allocator<unsigned int> >::_Rep::_M_destroy ()
   from /usr/pkg/lib/libscim-1.0.so.10
#8  0x28fbd5c0 in std::basic_string<unsigned int, std::char_traits<unsigned int>
, std::allocator<unsigned int> >::assign () from /usr/pkg/lib/libscim-1.0.so.10
#9  0x28fe465f in scim::TransactionReader::get_data ()
   from /usr/pkg/lib/libscim-1.0.so.10

そもそもucs4_t自体気に入らんのでCSIに書き直してぇ。
まぁそれかC++0xの実装が出揃うまで放置して、char32_tって手もあるのか(ぉ

2009/02/02(Mon)

[NetBSD] pkgsrc/wip/scim

最適化がらみなのか、-O2とっぱらったらgtk2相手でも落ちなくなったにゃ。
しかしC++でgdbは非力過ぎて氏ねる。

NetBSDの方でも最適化とっぱらって動かしてみたら、違うとこで落ちた。
これはwchar_t = ucs4_tの場合でも発生するのでchar_traitsとは無関係っぽ。

0xbaa7fdb0 in ?? ()
(gdb) bt
#0  0xbaa7fdb0 in ?? ()
#1  0xbacdf8d1 in gtk_im_context_scim_shutdown () at gtkimcontextscim.cpp:456
#2  0xbacf22fe in ~FinalizeHandler (this=0xbacffb28)
    at gtkimcontextscim.cpp:322
#3  0xbacdfa20 in __tcf_10 () at gtkimcontextscim.cpp:326
#4  0xbb3c59c6 in __cxa_finalize () from /usr/lib/libc.so.12
#5  0xbacddbd4 in __do_global_dtors_aux ()
   from /usr/pkg/lib/gtk-2.0/immodules/im-scim.so
#6  0xbacf6d08 in _fini () from /usr/pkg/lib/gtk-2.0/immodules/im-scim.so
#7  0xbbbf5e47 in _rtld_call_fini_functions () from /usr/libexec/ld.elf_so
#8  0xbb70b200 in ?? ()

もういややー、今の気分 こんなかんじ

他にもGTK2アプリ終了時に

/usr/lib/i18n/libGBK2K.so.5.0: Trying to call undefined weak symbol `__deregister_frame_info'

ちゅーメッセージが出る時があるんだな。

現在のlocaleはzh_CN.GB18030ではないので、このencoding moduleはloadされてないはずなんだが。
多分 lib/39986と同件っぽい、なんかld.elf_soに虫さんがいるような気がする。
こないだDF_1_INITFIRST関連で.ini/.finiセクションの実行順いじったのがなんか悪さしてるのかも。

それとchar_traits<ucs4_t>がscim_chartraits.cppにあるっちゅーのは変なので
scim_types.hにごっそり移してみた、 patch
つかscim_chartraits.hとして、scim_types.hがincludeする方がいいのかも。

2009/02/03(Tue)

[NetBSD] pkgsrc/wip/scim

finalizeで死ぬのはFreeBSDでも同じだった、そもそもfinalizeでscimは何やってるんだ?

結局Trying to call undefined weak symbol `__deregister_frame_info'問題とか
今のNetBSD HEADのgccとlibgcc_sがさっぱり信用ならんので
pkgsrc/wip/gcc43をインスコしてscimをbuildしたら完全に問題は解消した、やっぱおまいか。
ということでNetBSDのgcc41とFreeBSDのgcc42でC++するのは止めとけってことで。

しかしこれは困った、5.0をこんなアヤスィ状態のgcc41でリリースしていいのかなw

関係ないけど、64bit time_tでX + wsmouseがぶっ壊れたままなんですが修理まーだー?
いちおpatchがtech-x11流れてるけど、これ当ててもVT switchするだけで動作がまた変になりよる。
まだ/dev/psm0(だっけ?)って使えたかしら…

[NetBSD] libgcc_s

__deregister_frame_infoってlibgcc_sのsymbolなんだけど、libcにDF_1_INITFIRSTつけたせいで
libgcc_sがunmapされた後に__deregister_frame_infoが呼ばれてundefined symbolになってるとかかな。
でもそれなら毎回起きるはずなんだが…

これ気になるな、怪しい。

$ ldd /usr/pkg/gcc43/lib/libgcc_s.so.1
/usr/pkg/gcc43/lib/libgcc_s.so.1:
        -lc.12 => /usr/lib/libc.so.12

$ nm /usr/lib/libgcc_s.so.1.0 | grep __deregister_frame_info
0000778c T __deregister_frame_info
0000768c T __deregister_frame_info_bases

$ ldd /usr/lib/libgcc_s.so
/usr/lib/libgcc_s.so:

$ nm /usr/pkg/gcc43/lib/libgcc_s.so.1 | grep __deregister_frame_info
0000840c T __deregister_frame_info
00008328 T __deregister_frame_info_bases

$ nm /lib/libc.so.12.164  | grep deregister
         w __deregister_frame_info

手元のFedora Coreの場合

$ ldd /lib/libgcc_s.so.1
        linux-gate.so.1 =>  (0x00110000)
        libc.so.6 => /lib/libc.so.6 (0x0011d000)
        /lib/ld-linux.so.2 (0xb7f4f000)

$ nm -D /lib/libgcc_s.so.1 | grep __deregister_frame_info
000080e0 T __deregister_frame_info
00007ff0 T __deregister_frame_info_bases

$ nm -D /lib/libc.so.6 | grep __deregister_frame_info
0010afc0 T __deregister_frame_info
0010b4e0 T __deregister_frame_info_bases

うーむ、libgcc_sはlibcへの依存関係を記録しておく必要あり?

2009/02/04(Wed)

[NetBSD] いろいろ

current-user、いっそのことiconv(3)弄って//TRANSLITとか
ホイホイ喰っちまって捨ててしまうようにした方がいいような気がしてきた。

昨日のHEADに入替えたらstartxで100%刺さるようになった、currentっぷりにおらワクワクしてきたぜ!

pkgsrc/wip/scimの状況を整理すると:

  1. char_traitsをspecializeすると、basic_stringでoperator=を使ったとき
    char_traits::assign内でクラッシュする、おそらくjunk pointerをfreeしてる

    これは最適化(-O?)で顕在化するバグのようで最適化しない or gcc43を使うとこの問題は発生しない

  2. アプリケーション終了時にmemory faultが発生する

    これもchar_traitsをspecializeすることで発生する、最適化の有無に関わらず発生するが
    gcc43を使うとこの問題は発生しない。

  3. 必ずではないが、weak symbolである__deregister_frame_infoが解決できず落ちる

    多分NetBSD specificな問題くさい(ld.elf_so? libgcc_s?)どうやらFreeBSDではこの問題は発生しない。
    というかFreeBSDの場合、__deregister_frame_infoは呼ばれない?
    (ちなみに問題の発生しない環境は全てlibgcc_sはlibcへの依存関係を記録してる)

という3つの問題が渾然一体とワケワカメ状態なので正直めんどくさくなってきたw

それにしても

ちゅーなんでこんなおいらの趣味と正反対のアプリをデバッグしてんだろ状態。
this must be the ugliest piece of bread i've ever eaten、ジャムでしょ?

2009/02/05(Thu)

[NetBSD] C runtime object

FreeBSDではcrtbegenT.oをリンクしない限り__(de)?register_frame_infoは使われない模様。
確かこいつらってC++の例外でstack frame情報の取得に使うんだったっけ?

じゃぁ何でNetBSDはcrt{begin,end}がこいつら使ってるんだって話かな。
まぁlib/39986の解消とは本質的にはかんけーないのだけど。
あれはやっぱりlibgcc_sが思いがけないタイミングでunloadされてる希ガス。

あたりが 臭いなぁ、なかなか再現もしないので正直理詰めでデバグするしかないのだが
オツムが足りてないのが困る。

main()の前とexit()の後は知っちゃなんねぇとばっちゃがいってた。

TODO、真面目にELF/DWARF2の仕様書を読む。

うーん、gtk-demoをgdbで動かしてみる限り、

で、うまいこといってるっぽいぞ。そうすっとやっぱld.elf_soなのかな。

2009/02/06(Fri)

[NetBSD] pksrc/wip/scim

gcc43でbuildしても実はダメでした(笑)
scim-1.4.7/extras/gtk2_immodule/Makefile*が腐ってるのかc++ -sharedだとそういうもんなのか
libgcc_sがリンクされず、gtk-query-immodules-2.0がコケて登録されず
gtkimmoduleでなくxim経由で入力できてるだけでした、もういやこのinputmethod。

そもそもpure CのGTK2がC++のscim immoduleをdlopen(3)すること自体いいんだろか。
こないだの非pthreadアプリがpthreadなshlibをdlopen(3)するとアウチな件と
なんか同じ根っこの問題があるような気がしないでもない。

あとで読む
読んだけどろくな事書いてなかった orz

やっぱC++も勉強しないとダメだな、BSDLなlibstdc++があればねー。

__deregister_frame_info問題はさていおて、終了時にクラッシュする問題を片付けるべく
extras/gtk2_immodule/* を読もうと決意したが、gtk2のcallbackによる終了処理と
C++のdestructorでの終了処理がいりまじって、とっても危険な 臭いが…

2009/02/07(Sat)

[NetBSD] pkgsrc/wip/scim

すっかりwchar_t as UCS4のような文字コード問題だと思ってたので、そっち方面は調べてなかったのだけど
gtkimmoduleを使う場合にゲーロ吐いて氏ぬのはFedoraでも一緒で、こんなlocal patchをあててるのだな。
(追記) SuSEのsrpmみるとscim-launcherの問題っぽい。

diff -Nur scim-1.4.5/src/scim_frontend_module.cpp scim-1.4.5-fix/src/scim_frontend_module.cpp
--- scim-1.4.5/src/scim_frontend_module.cpp     2005-01-10 16:30:54.000000000 +0800
+++ scim-1.4.5-fix/src/scim_frontend_module.cpp 2006-11-17 14:30:56.000000000 +0800
@@ -69,7 +69,9 @@

         m_frontend_init (backend, config, argc, argv);
     } catch (...) {
-        m_module.unload ();
+    /* FIXME: scim does not unload cleanly, so just skip unloading for now.
+        m_module.unload ();
+     */
         m_frontend_init = 0;
         m_frontend_run = 0;
         return false;

どうみても対症療法パッチです、本当にあ以下略。

というかPure CなGTK2からdlopen(3)するアプリでC++の例外を使ってる自体
死亡フラグの気がする…まずは何でこの例外が起きてるのか調べるか。
NetBSDでもこのpatchをあてると__deregister_frame_info問題以外は 動いてるように見える。やっぱダメ。

というか、pkgsrcではgtkimmoduleはoffにしちまった方がいいような気がする。
あまりにコードが[お察しく下さい]過ぎるわこれ…

今日

the Pop Group Documentaryとかktkr! というか誰が得するんだよ状態。
ツレの中でも喜ぶ香具師は2人くらいしかいねーぞw

Tom WaitsがリマスタされてるけどSHM-CDなので買うのやめた。
そういやTom Waitsがロイツマ(Ievan Polkka)歌ってもあんま違和感ないよな。

某スレ読んで、そのうち[ck]?shのmultibyte対応やらなあかんTODO思い出した。
あとLANG=ja_JP.CP932ってやっぱ必要かな、現状mount時にUTF-8なんかへコード変換する機能ないし。

ほんとは変換なしでmout(つまりCP932)した上で適切なlocale(LANG=ja_JP.CP932)を設定して
ファイル操作するのが理想と思うのだが、如何せんそうすっとMSがサポートするcodepage全部必要になっちまうので
どうみもkludgeなれどもコード変換機能は必要かなぁとは思う、しかしkernel iconvを実装する人が以下略

ま゛理想をいえば、filesystemの文字コードとlocaleの文字コードは協調できるようにする必要があるのよね。
LANG=ja_JP.eucJPで動いてるアプリが、UTF-8 filenameなfilesystemに書き込む時って、今のところ
アプリ側でそのfilesystemの文字コードを意識してコード変換してやらんとダメなのでどうみてもオワットルわけで。
まぁこれはopen(2)をopen(3)にするとか、実際のsyscallには文字コード名を引数として増やしてkernel iconvあるいは
wide-character filename syscall(これCSIで実装しようとすると結局Citrusをkernelで持つというアレなことに)が必要になるのよな。
POSIXがこのへん黙り込んでる間は手を出したくないしな。

libc内で文字コード変換処理が閉じれればいいのだけど、この段階ではfilesystemの文字コードを知る方法がないのがね。
例えば文字コード情報を取得するのにstat(2)を拡張するっても、stat(2)を呼ぶのに文字コードが判らないと以下略。
金庫を開けるのに鍵は金庫の中状態、おいらkernelよう知らんからアレですがなんか抜け道あるのでしょうか。

current-users、Desktop NetBSDだと。twmのこと?(ぉ

2009/02/08(Sun)

[NetBSD] pkgsrc/wip/scim

SuSE Linux 11.1がscim標準だったはずなのでインスコしてみた。
なぜかscim標準のgtkimmoduleでなしに scim-bridgeを使ってる、なんぞ?

ちゅうかscim-bridgeのプロジェクトページに

You can use this to avoid the problem caused by C++ ABI transition.

とか書いてありやがんの、あsdfghjkl
まぁ今回の件は同じverのgcc/g++だから違うんだけど、やっぱりC++以下略

まぁでも、SuSEだとGTK_IM_MODULE=scimで起動してもクラッシュしないのだね。
ちょっとこの環境で調べてみますか。

とりあえずNetBSDの場合にはstatic objectのdestructorで氏にまくりなので
こんな patchでMemory Fault発生しないようにした。
class ConfigPointerがなぜ明示的に初期化せんと落ちるのかはよく判らんけど
FinalizeHandlerはGTK2のim_module_exit()イベントですでに終了処理は終わってるので
冗長な処理だし不要だと思われ、まぁC++だとdestructorで終了処理するのが定石みたいだけど。

あとは__deregister_frame_info()問題とg++のchar_traits最適化問題かぁ。
もうC++爆発しろ!

今日

current-users、本場物の " In Soviet Russia" ワロタ。

[NetBSD] __deregister_frame_info

まずはC++で書かれたshlibとC以下同文をdlopen(3)する簡単なサンプルを書いてテスト。

$ cat >foo.h
#if defined(__cplusplus)
extern "C" {
#endif
void foo(void);
#if defined(__cplusplus)
}
#endif
^D
$ cat >foo.cpp
#include <string>
#include <iostream>
#include "foo.h"

void
foo(void)
{
        std::basic_string<char> msg;
        msg = std::basic_string<char>("hello, C++ world.\n");
        std::cout << msg;
}
^D
$ g++ -shared -g -o libfoo.so foo.cpp
$ cat >bar.h
void bar(void);
^D
$ cat >bar.c
#include <stdio.h>
#include "bar.h"

void
bar(void)
{
        printf("hello, C world.\n");
}
^D
$ gcc -shared -g -o libbar.so bar.c

結果、Trying to call undefined weak symbol `__deregister_frame_info'が発生するのは
dlopen(RTLD_GLOBAL)でloadした場合かつ、C++なshlibをdlclose(3)してからC以下同文のみ。

$ cat >buzz.c
#include <dlfcn.h>

typedef void (*func_t)(void);
int
main(void)
{
        void *foo, *foo_func, *bar, *bar_func;
        foo = dlopen("/home/tnozaki/libfoo.so", RTLD_GLOBAL);
        foo_func = dlsym(foo, "foo");
        ((func_t)foo_func)();
        bar = dlopen("/home/tnozaki/libbar.so", RTLD_GLOBAL);
        bar_func = dlsym(bar, "bar");
        ((func_t)bar_func)();
        dlclose(foo);
        dlclose(bar);
        return 0;
^D
$ gcc -g -o buzz buzz.c
$ ./buzz
hello, C++ world.
hello, C world.
/home/tnozaki/libbar.so: Trying to call undefined weak symbol `__deregister_frame_info'

じゃ単純にRTLD_LAZYあたりに書き換えりゃいいかってーとそうでもなくて
Solarisの ドキュメントにはRTLD_GLOBALを使わないと例外も使えないともある、うーみゅ。

2009/02/09(Mon)

[NetBSD] __deregister_frame_info^2

FreeBSDのcommit logみると こんな対応してるみたいだけど
このdiffのようなfake symbolをセットする対応自体はNetBSDもとっくにやっとるので関係ないな。

        /*
         * If we found no definition and the reference is weak, treat the
         * symbol as having the value zero.
         */
        if (def == NULL && ELF_ST_BIND(ref->st_info) == STB_WEAK) {
                if (in_plt) {
                        _rtld_error(
                            "%s: Trying to call undefined weak symbol `%s'",
                            refobj->path, name);
                }
                rdbg(("  returning _rtld_sym_zero@_rtld_objself"));
                def = &_rtld_sym_zero;
                defobj = &_rtld_objself;
        }

src/libexec/ld.elf_so/arch/i386/mdreloc.cの_rtld_relocate_plt_objectとか眺めた感触としては
やっぱりcrtbeginS.o *1は__(de)?regisrer_frame_infoへのweal referenceを持ってたらダメな気がするんだよな。

NetBSDの場合のリンクオプション

$ gcc -### -shared -o libbar.so bar.c
Using built-in specs.
(中略)
"ld" "-shared" "-o" "libbar.so" "/usr/lib/crti.o" "/usr/lib/crtbeginS.o" "/var/tmp//ccgdmwa0.o"
"-lgcc_pic" "-lc" "-lgcc_pic" "/usr/lib/crtendS.o" "/usr/lib/crtn.o"

$ nm /usr/lib/crt*S.o | egrep "__(de)?register_frame_info"
         w __deregister_frame_info
         w __register_frame_info

Linuxの場合の以下同文

$ gcc -### -shared -o libbar.so bar.c
Using built-in specs.
(中略)
"/usr/libexec/gcc/i386-redhat-linux/4.3.2/collect2" "--eh-frame-hdr" "--build-id" "-m" "elf_i386"
"--hash-style=gnu" "-shared" "-o" "libtest.so" "/usr/lib/gcc/i386-redhat-linux/4.3.2/../../../crti.o"
"/usr/lib/gcc/i386-redhat-linux/4.3.2/crtbeginS.o" "-L/usr/lib/gcc/i386-redhat-linux/4.3.2"
"-L/usr/lib/gcc/i386-redhat-linux/4.3.2" "-L/usr/lib/gcc/i386-redhat-linux/4.3.2/../../.."
"/tmp/ccKHu6ho.o" "-lgcc" "--as-needed" "-lgcc_s" "--no-as-needed" "-lc" "-lgcc"
"--as-needed" "-lgcc_s" "--no-as-needed" "/usr/lib/gcc/i386-redhat-linux/4.3.2/crtendS.o"
"/usr/lib/gcc/i386-redhat-linux/4.3.2/../../../crtn.o"

$ nm /usr/lib/gcc/i386-redhat-linux/4.3.2/crt*S.o | egrep "__(de)?register_frame_info"

ちゅうことで、crt*のソースを眺めてみると、--eh-frame-hdrつきでリンクすりゃ
__(de)?register_frame_infoは不要ってことみたい、src/gnu/dist/gcc4/gcc/crtstuff.c参照。

 89 #if defined(OBJECT_FORMAT_ELF) && defined(HAVE_LD_EH_FRAME_HDR) \
 90     && !defined(inhibit_libc) && !defined(CRTSTUFFT_O) \
 91     && defined(__GLIBC__) && __GLIBC__ >= 2
 92 #include <link.h>
 93 # if (__GLIBC__ > 2 || (__GLIBC__ == 2 && __GLIBC_MINOR__ > 2) \
 94      || (__GLIBC__ == 2 && __GLIBC_MINOR__ == 2 && defined(DT_CONFIG)))
 95 #  define USE_PT_GNU_EH_FRAME
 96 # endif
 97 #endif
 98 #if defined(EH_FRAME_SECTION_NAME) && !defined(USE_PT_GNU_EH_FRAME)
 99 # define USE_EH_FRAME_REGISTRY
100 #endif

288 #ifdef USE_EH_FRAME_REGISTRY
289 #ifdef CRT_GET_RFIB_DATA
290   /* If we used the new __register_frame_info_bases interface,
291      make sure that we deregister from the same place.  */
292   if (__deregister_frame_info_bases)
293     __deregister_frame_info_bases (__EH_FRAME_BEGIN__);
294 #else
295   if (__deregister_frame_info)
296     __deregister_frame_info (__EH_FRAME_BEGIN__);
297 #endif
298 #endif

しかしそれNetBSDやるとかなりの大災害だよね、バイナリ互換なくなる気がするんだけど
そうすっとまーた全部再コンパイル以下略

結局はld.elf_soでいちいち警告出してるのを黙らせるしかないんじゃないかという感触。
in_pltフラグをゴニョるか引数増やしてもいっこflag立てるか。

*1:crtbeginS.oが-sharedで、crtbeginT.oが-staticでlinkされる。

今日

ギクリ、現状Citrusのドキュメントって

しかないのでやらんとまずいのですよね、某developerにも散々文句いわれてますし *1

政府紙幣、一方アメリカは貧困層にクレカをばら撒いた、ばら撒いた結果がこれだよ!
20万で金買ってインフレに備える使い道が一番多かったりしそうな日本人。

*1:しかし返事書いてない(苦笑)