scim-helper-managerのcoreダンプをなんとかしたい

いつのころからか、ホームディレクトリにscim-helper-manager.coreができるようになっており、XfceにあるSCIMのアイコンを右クリックしても「SCIMを設定」のメニュー項目が出なくなってしまっていた。

これに関する最初の記述は、たぶん、[FreeBSD-users-jp 91512] 7.0-RELEASE で scim-helper-manager.core から始まるスレッドで、途中でsetupモジュールをロードするところがおかしいというところまで追求しているものの、いつのまにか ltdl.cpp 内で try_dlopen() が成功したら（エラー数が0なら）エラーを返すとかいう意味のわからない解決に終わってしまっている。

それ以外では、かけまわる子犬。: scim-helper-manager.core の core うざい・・。 で、.xsession 内で（kde起動前に） skim を起動することで、coreダンプしなくなるという記述があるが、何らかの依存関係が解消したなどの根本的な解決ではなさそうである。

また、めもがき:2009年1月中旬 によれば、NetBSDでも同様な問題があって、libpthreadがらみではないかという結論に至っている。

さらに最近、2chの FreeBSDを語れ Part23 にも関連の話題があり、NISユーザだと発生するだの、-gやgcc34を使えばいいだの、スレッドがらみでデバッグが困難だの、いろいろ情報が書かれている。

自分でも何とか解決できればと、SCIM 1.4.9を探し出して自家portを作ってみたり、コンパイラを変えてみたりしてみた。NISユーザの場合は、getpwuid() 内の getpwent_r() から呼ばれた yp_match() 内のさらに奥の _pthread_main_np() 内で落ちているということまではわかったが、libc を -g で作ってまで調べるには気合いと時間が足りない。それでも何とか、あちこちにデバッグプリントを入れてみたみたところ、どうやら dlopen/dlclose が関連している可能性が高く、ltdl.cpp 内の sys_dl_close() にある dlclose() を呼ぶ部分で、これを呼ばずにいきなり return してしまえば、とりあえずは落ちなくなることがわかった。

パッチはこんな感じ。

--- ./src/ltdl.cpp.orig 2008-11-02 15:42:40.000000000 +0900
+++ ./src/ltdl.cpp      2009-05-07 18:11:26.000000000 +0900
@@ -1073,6 +1073,7 @@
sys_dl_close (lt_user_data loader_data, lt_module module)
{
int errors = 0;
+  return errors; // Avoiding FreeBSD core-dump; don't know why this works

if (dlclose (module) != 0)
  {

この続きは気力次第。


追記（5/11）

早速にも めもがき:2009年5月9日分 にて、詳しい解説つきのフォローをいただきました。ありがとうございます。

ビルド時のログをとって調べてみると、確かにライブラリのリンク時には -pthread がついていて、親のバイナリにはついていなかったりする。

というわけで、Makefileをいじって、configureに渡すLDCONFIGに -pthread を追加してみたところ、ぴたりと問題はおさまった。パッチを作って、メンテナに連絡してみたりする。

ところで、uim への乗り換えも検討して試してみたりしたことはあるのだが、どうもキーバインディングなどの微妙な問題なのか、uim-skk の使い勝手が悪い。xterm/kterm 上で Enter がわりに（Ctrl-M より楽だから）Ctrl-J を押す癖があることも一因かもしれないけど、firefox 上でもなんかバタバタして状態の把握がうまくできない。なので uim はお預け。最近 anthy 版portの出た ibus に注目中。

FreeBSDのportsでmake installするときは-dlなど禁止

makeの -dl は、makeが実行するコマンドをすべて強制表示させるオプションで、Makefileなんかで非表示にしたコマンドも表示されるので、デバッグに便利な機能である。

portsのmake時にいったい何が起きているのかを表示させようと、portupgrade -f -m -dl hoge とかやってみたところ、たしかに期待どおりに表示されるのだが、もう一度portupgradeしようとすると、

Stale dependency: hoge --> ] -- manually run 'pkgdb -F'...

とか言われるようになり、pkgdb -F をするはめになる。そうすると何やらわけのわからない依存関係が多量に削除される。

で、hoge/+CONTENTS を見てみたら、多量のゴミが。

しばらく bsd.port.mk と格闘したところ、fake-pkg のターゲットで Registering installation for hoge と表示した後の処理で使う PKG_ARGS の展開結果がおかしい。その定義はというと、make actual-package-depends を実行した結果を加工している。つまり、このmakeの実行時に -dl が有効になってしまって、ゴミが出力され、それも含めて加工した結果をpkg_createに渡しているせいで、+CONTENTSが壊れるということらしい。

makeが子makeを呼ぶときに .MAKEFLAGS を渡すが、この中から -d* を探して削除するというコードが必要になる。とってもめんどくさそうなので、make install時に限っては -d* をつけないことにする。

あとでpkgdb -Fすればいいんだから簡単じゃないかとも思えるが、-dg2 とかしたらpkgdb -Fの後でもpkg_deleteがcoreを吐くとかいう事態になる。


追記（5/7）

デバッグオプションを取り除いて子makeを呼ぶコードを書いてみた。

--- bsd.port.mk.orig 2009-04-10 07:40:20.000000000 +0900
+++ bsd.port.mk 2009-05-06 13:36:11.000000000 +0900
@@ -2384,7 +2384,18 @@
.endif

.if !defined(PKG_ARGS)
-PKG_ARGS=              -v -c -${COMMENT:Q} -d ${DESCR} -f ${TMPPLIST} -p ${PREFIX} -P "`cd ${.CURDIR} && ${MAKE} actual-package-depends | ${GREP} -v -E ${PKG_IGNORE_DEPENDS} | ${SORT} -u -t : -k 2`" ${EXTRA_PKG_ARGS} $${_LATE_PKG_ARGS}
+_MINUSD= -d
+. for _MAKEFLAG in ${.MAKEFLAGS}
+.  if ${_MINUSD} == ${_MAKEFLAG}
+_AFTERMINUSD= yes
+.  else
+.   if !defined(_AFTERMINUSD)
+_NODEBUGMAKEFLAGS+= ${_MAKEFLAG}
+.   endif
+.undef _AFTERMINUSD
+.  endif
+. endfor
+PKG_ARGS=              -v -c -${COMMENT:Q} -d ${DESCR} -f ${TMPPLIST} -p ${PREFIX} -P "`cd ${.CURDIR} && MAKEFLAGS=${_NODEBUGMAKEFLAGS} ${MAKE} actual-package-depends | ${GREP} -v -E ${PKG_IGNORE_DEPENDS} | ${SORT} -u -t : -k 2`" ${EXTRA_PKG_ARGS} $${_LATE_PKG_ARGS}
.if !defined(NO_MTREE)
PKG_ARGS+=             -m ${MTREE_FILE}
.endif

一応動いてそうなので、いつかのためにメモ。


追記（5/20）

やっぱりダメ。依存関係によってインストールされたパッケージに正常に@pkgdepがつかない。 -DINSTALLS_DEPENDS がうまくわかってない感じ。

moodleにJava appletを置こうとしてFirefoxのバグにはまる

moodleのコース内にちょっとしたJava appletを置くことにした。ウェブページリソースを作り、appletのためのタグの書きかたをすっかり忘れたので他のサンプルをみようみまねで挿入し、目的のjarファイルをアップロードして表示させてみると、指定したエリアだけ確保するもののappletがスタートしない。

FreeBSDのFirefox 2では動く。WindowsのFirefox 3では動かない、IE7では動く。Javaのコントロールパネルからキャッシュを明示的に消さないと、IE7で動いてしまった後はFirefox 3でも動いてしまって、途中大混乱したが、Google Chromeでも動く、Safariでも動く、ともかくFirefox 3で動かない。

apacheのログによると、303、つまりSee otherで、ログインページに飛んでいる。コースを表示中だからログインは当然している。なのにログインページに飛ばされるということは、MoodleSessionのクッキーをちゃんと送っていないということしかない。ログのフォーマットを変更してこのクッキーを表示させてみたら、たしかにFirefox 3のみ送っていない。他のブラウザは同じ Java RE で動いているので、Firefox 3のバグに違いない。

というわけで、Bugzillaで検索して出てきたのが、Bug 441166。「サードパーティの Cookie も保存する」のチェックをはずしていると、appletがクッキーを送らないらしい。原因はまさにこれだった。基本的に一部の例外以外はFirefox終了時にクッキーを消す設定にしているが、Firefox 3の導入時に、そういえばサードパーティCookieは拒否することにした気がする。Firefox 2にはそんな設定がなかったから問題が起きなかったわけである。

いちおう解決というか、Firefox 3にがんばってもらわないと好みの設定ができないわけで、その意味で当面解決不能。

フレッツ・光プレミアムのインストールツールではまる

いろいろあってNTT西の光プレミアムを入れることになり、VDSLモデムとCTUとVoIPアダプタをごちゃごちゃつける工事がなんとか終わって、とりあえずひかり電話が開通してることを確認してもらった。プロバイダとかの設定はどうするのときいたら、とにかくCD-ROMつっこんでそれでやってねと言い残して、工事の人は去っていった。モデムのマニュアルもCTUのマニュアルもほんの薄っぺらいものしかなく、必要なものはすべてCD-ROM内っぽい。

無用なトラブルを避けるために言われたとおりにCD-ROMをさし、無線LANは念のため使わず、CTUとPCをケーブルで直接つなぐ。CD-ROMに入ってるインストールツールを動かし、スタートアップツールのインストールを開始すると、途中で、「IPv6がインストールされていません。IPv6をインストールする必要があります。インストールしますか？」という半強制的なダイアログが出て、キャンセルする理由もないのでそのままOKし、とりあえず完了。次にインターネット接続設定に進むと、デフォルトブラウザじゃなくIE7が起動され、「[2001:d70:3:1::3:3] に接続しています。」状態から進まない。何度か試すと、ようやくCTUのログインページが表示されて、さらにプロバイダのID/パスワードを入力するページが表示されて、設定完了。Yahooなど主要サイトには問題なく接続できることを確認し、あっさりと、めでたしめでたし。

いや、違った。CTUの細かい設定などはどうするのだろうと思い、スタートアップツールを動かして、「CTU設定」をクリックしてみると、IEが開いて接続中のまま固まる。しかもCPUを100%食っているようである。https://ctu.fletsnet.com/ を直接Firefoxで開こうとしても症状は同じ。

ふと思いついて、ローカルエリア接続のプロパティからMicrosoft TCP/IP version 6のチェックをはずしてみると、あっさりつながるようになった。別のPCで、最初からIPv6のインストールをキャンセルしても同様。まったく問題なし。IPv6をインストールするとそのPCでもだめ。XP SP3がIPv6に未対応なのかとも思ったが、これほど一般的な環境で問題が起きるなら、NTTだって最初からIPv6を入れさせたりしないだろうし、まったく手がかりなし。

で、2chに頼って、光プレミアムのCTU設定スレがあるのをみつけ、IPv6で検索したら、NOD32は未対応のくそソフトとか、3.0なら対応してるとか。まったく盲点だった。家中のPCにはNOD32 v2.7が入っている。どのPCでもだめなはずだ。最初のインストールツールで1回であれCTUにつながった方が奇跡的だ。DNSのAAAA検索がうまくいかなかったか何かなんだろうか。

ためしに3.0にバージョンアップしてみたら（ライセンスはそのまま動くらしい）、IPv6下でFirefox, IEともに無事に接続できるようになった。ようやくめでたしか。

ところが、ともちゃ氏によるNTT西日本 Ｂフレッツシリーズ及び光プレミアムの裏側は、Bフレッツがらみの濃い情報がたくさんあるが、IPv6が生きている状態だとなぜだか接続できない（たまたま？）。