[debian-users:08706] Re: Problem in using ldconfig on hamm

[Mitsuru Oka <95i44@xxxxxxxxxxxxxxxx>]

岡＠情報科学.高知大です。

自己フォローです:
近棟>  試しました．一応，Linux を普通にリブートすれば fsck のエラーは無くな
近棟> るみたいでした．ただ，/ を umount して e2fsck をかけるとかの作業をする
近棟> とエラーを吐きますね( init 以外のプロセスが mmap してるから)．ささやま
近棟> さんの推測通りでした．
近棟>  古い libc5 な Slackware では，fuser /etc/ld.so.cache しても，何も出力
近棟> されません．こうなってるのが正常のような...。
岡> ということは、init に限らず普通のプログラムでも問題がある、
岡> つまりどのプログラムにも共通するということは、共有ライブラリ
岡> に問題があるのでは?
...
岡> libc6 と ld-linux が共通するライブラリです。ソースを当ってみ
岡> ましょうか?

整理を兼ねて、簡単に纏めると:

/ を umount する時に init は /etc/ld.so.cache をマップしてい
る。これが原因でfsckに引掛る。

この現象は手動で umount することで、init 以外のプログラムで
も引き起こすことができる-> init 固有の問題では無いらしい。

どのプログラムも /etc/ld.so.cache を map したままになってい
るのは、共有ライブラリに関係する可能性が高い(僕の意見として)。
これに関係するのは ld-linux.so.2(1.9.9もあるが使われていない)、
libc6 ではないか。



どちらも glibc のソースに含まれているので調べてみました(2.0.7t)。
結局バグレポートを当ってみたところ、

  http://www-gnats.gnu.org:8080/cgi-bin/wwwgnats.pl/full/759

があやしいです。slinkでの再現性が無いという点を考慮(slinkで
は現在2.0.7uになっている)するとわりと可能性は高いかもしれな
いです。ちなみに glibc のソースで言うとこれは:

  glibc-2.0.7t.orig/elf/dl-close.c

で、ELF 固有のバグらしいです。

これが確かなら、「slink の libc6 に移行することで解決」でよ
さそうです。
--
岡 充 (Mitsuru Oka)
高知大学情報科学科4回生
E-Mail:95i44@xxxxxxxxxxxxxxxx