libsmbclient + nss_wins の問題 (2)

昨日は間違ったことを書きました。

debug_add_class()static ではなくて外部に露出したシンボルだから(そしてその中でだけ変数 DEBUGLEVEL_CLASS を設定しているから)問題ないはずなのです。

昨日の例だと,下記のようなフローになるはず。

  1. main が libsmbclient.so をロードする
  2. DEBUGLEVEL_CLASS を resolve in libsmbclient.so
  3. libc::gethostbyname() を呼び出す
  4. nsswitch によって libnss_wins.so がロードされる
  5. DEBUGLEVEL_CLASS はすでに libsmbclient.so にマップされている
  6. debug_add_class()libsmbclient.so にマップされている(はず)
  7. libsmbclient.so::debug_add_class()realloc(NULL)
  8. ウマー


かといってまったく間違っていたわけでもなさそうです。

デバッグログを出力するようにパッケージをビルドして,debug_add_class() に仕掛けてみました。

そのログ

 DEBUGLEVEL_CLASS     = 0xb7f9306c
&debug_all_class_hack = 0xb795770c

fault 時のデバッグログからメモリマップを抜粋

======= Memory map: ========
b794f000-b7959000 rw-p 000d4000 fe:01 92364867   /lib/libnss_wins.so.2
b7f8a000-b7f95000 rw-p 00206000 fe:01 110439431  /usr/lib/libsmbclient.so.0.1

ということで,変数 DEBUGLEVEL_CLASS の中味は libsmbclient.so を示しています。一方,debug_all_class_hacklibnss_wins.so.data セクションに存在するようです。ま,つまり,このログを吐いたのは libnss_wins.so::debug_add_class() になりますね。先ほどの考えだと,ここは libsmbclient.so::debug_add_class() になるはずです。謎。


ちなみに RH 系の CentOS 5.1 でテストしたところ,エラーになりませんでした。

念のために,彼の Samba は 3.0.25b ベースです(Ubuntu Hardy は 3.0.28a ベース)。でも今回の部分に関連する違いがあるようには見えませんでした。


うーん。Ubuntu の libc → nsswitch あたりでの dynamic load 機構がおかしいのかしら。あるいはそもそも共有ライブラリのロード→データセクションの初期化まわりがおかしい?


とりあえず実運用上 nscd 経由にしてみようかなぁ。