libsmbclient + nss_wins の問題 (2)

linux memo

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

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_hack は libnss_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 経由にしてみようかなぁ。