[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

[FDclone-users:00609] Re: 仕切り直します。



 しらいです。

In Message-Id <20061004194235.476399.10cbefc2@isis.ocn.ne.jp>
        yuji tamura <yuji@isis.ocn.ne.jp>さんwrites:
> こんばんは、田村です。

> a) + c) readfilelist() の「buf[1024]」で
> patch を当てて、config.h に3行追加
> 「/Users/yuji/Documents/」において
> 「10 blog/」と言うディレクトリ名が消える事を確認
> 「/User2/yuji/Documents/」において
> 「6 www」と言うディレクトリ名が消える事を確認

 うう、話が違うじゃないですか。[FDclone-users:00607] ではこ
の設定で症状が解消した筈だったのに、単に再現性が低かっただけ
なんでしょうか。
 という訳で、MAXNAMLEN に関する検証は全て無駄になりました。
他を当たりましょう。


> >  並行して [FDclone-users:00579] で MAXPATHLEN の値を調べた
> > のと同様の手法で MAXNAMLEN の値も調べておきましょうか。
> 
> 「255?n」となるようです。

 「\」が「?」と表示されるようならそれはそれで問題ですが、こ
れは単に入力ミスしただけですよね?もしミスじゃないとしたら、
Virus か何か疑った方がいいかも。OS が根本的にイカれてます。


> >  Makefile に「#CPPFLAGS = -DUSG」って行があるので、この行頭
> > の「#」を削除して make するとうまく行くかも知れません。
> 
> こっちでうまくいきました

 うわちゃー、こうなると益々 malloc() の bug の可能性が高く
なってしまいましたねー。OS version の依存性があるところから
見ても怪しいし。
 どなたか Mac OS X 10.4.8 でこの手の bug report を聞いてい
ないでしょうか?

# あれ?読み返してみたら最初は 10.4.7 と言ってませんでした?


 まぁ無碍に OS のするのも申し訳ないので、週末辺り手が空いた
ら memory 管理の検証を行なってみますね。
 GNU malloc は memory leak に強いという性格を持っているので、
ちょっとやそっと使い方を間違えたくらいでは平気で動作したりす
るものです。
 GNU malloc には MALLOC_TRACE という memory trace 用の環境
変数があって log を取れるようになってるので、この機能を使っ
て malloc() 周りの挙動を追ってみたいと思います。


> 「/Users/yuji/012345678901234567/」
> 「/Users/yuji/Documents/10 blog/」
> 「/Users/yuji/Documents/」
> 「/User2/yuji/Documents/10 blog」
> 「/User2/yuji/Documents/」
> 
> 割とひんぱんに再現していた、上記ディレクトリにおいて、
> 今のところは再現ゼロです。

 これは libmalloc を link しただけで、他は素の 2.09 のまま
ですよね?だとすると strdup2() のところで何か起こっているの
かも知れません。
 素の 2.09 に strdup2() の改造を施してから同じ検証をやって
みましょうか。libc.c: strdup2() の中に malloc() が一箇所あり
ますが、この引数を「(ALLOC_T)n + 1」→「(ALLOC_T)n * 2 + 1」
と変えてみて下さい。
 これで strdup2() は常に必要サイズの倍の領域を確保するよう
になるので、memory leak が防げるようになるかも知れません。


> と言う構成にしていたのですが、「/User2/yuji/Documents/」以下は
> ファイルまで同じ構成にしていたのです、構成構築を楽にしようと思い
> ディレクトリだけ残して、ファイルはみんな、削除したのですが、
> それからは、素の fd v2.09 でも再現しないのです。

 directory 内の file が多いとそれだけ大量の strdup2() が実
行されるので、ある程度の数が必要になるのでしょう。


> もしそうだとすると、他機で再現確認するのは難しいのではと言う気が
> します。
> もうちょっと再現確認して見ます。

 再現可能な directory 構成が構築出来たら、その構成を tar に
して添付して下さい。file name だけの問題なので、file size を
全部 0 にすればそんなに大きな tar ball にはならないでしょう。
 こちらの方は小島さんの側でもケアしてあげて下さい。

                                               しらい たかし