#全く動かないPCの方で、もう少し調べました。
#libioread_line -> Scm_ReadLine -> readline_body -> Scm_GetbUnsafe -> bufport_fill と呼ばれ、bufport_fill内の do ループに入って直ぐのint r = p->src.buf.filler(p, toread-nread);から返ってきません。
#何かヒントがあれば教えてください。いろいろやってみます。
#p->src.buf.filler()の飛び先を調べるのは少し面倒だけど、そこに入らないと駄目っぽい。
#ソケットポートはソケットのfdを使ってScm_MakePortWithFdで作られてるので、そこで呼ばれてるのはsrc/port.cのfile_fillerのはずです。
#ありがとうございます。printf()入れてみます。
#file_filler に入って、SCM_SYSCALL(r, read(fd, datptr, cnt-nread));から戻ってきてないです。readの引数は、fd = 4 dataptr = 02737000 cnt-nread = 8192 です。この後はリンクされているlibcのread()呼んでるのかな。
#そこからはlibcの中ですね。うーむ、WindowsのPOSIX fdの扱いはどうもおざなりなのがなあ。
#Unixならここでstraceあたり使うところだけど、Windowsだとどうすべきか
#む、もうひとつ可能性が。SCM_SYSCALLは呼び出し(ここではread())がEINTRでエラーになった場合、割り込みを処理してからread()を再試行します。Windowsではシグナルが無いのでEINTRが返ってくることはないはずなんですが、もしかして何らかの理由によりEINTRが返って来ちゃって、処理するシグナルがなくてread()をひたすら呼び出してるって可能性があったりして。static int dummy_read(int, void*, size_t)みたいなダミー関数を作ってprintfしてread呼ぶようにして、SCM_SYSCALL(r, dummy_read(...)) とかしたらread()で本当に刺さってるのか無限に呼び出してるのかわかるかな。
#ありがとうございます。明日もう一度tryします。
Gauche > Archives > 2012/10/10