as I am also a victim of the netscape freezing, I have
done some tests. I didn't follow all the discussion, so
perhaps what I write is duplicate, but I think
it is nevertheless interesting.
My environment is 2.2.0-final, Netscape 4.5, glibc 2.0.7,
egcs 1.1.1.
First I have located one html page where the Netscape
always freezes, even when loading from local disc.
In my environment such page is e.g. the main page
from developer.intel.com.
Then I have done a strace, located the pipe and counted
the reads and writes. No suprise - the lock happened
after the write count exceeded the read one by 4096.
The write then blocked.
So I have written a small LD_PRELOAD library, which
overloaded pipe, read and write, added some detection
logic for the given pipe and started experimenting.
I have modified the write so that it fakes successfull
write if the pipe is full. The Netscape still
did not run, but this time the blocking call
was read.
Then I counted the faked writes and faked the
corresponding reads too. The Netscape runs without
problems now and the number of reads matches
the number of reads at the end of the run.
The maximal difference between writes and
reads was 17011!
I tried to return EWOULDBLOCK from the excessive
writes - this did not help and I got blocking
read - the thing does want the same number
of reads and writes.
So the situation is quite clear. Kernel is OK,
and the Netscape is buggy, as it reads and writes
without querying if it is possible and cannot live
with limited pipe buffer size. I am unable to guess
how complicated it would be to allow greater pipes,
but it is most probably not the right thing to do
(_POSIX_PIPE_BUF is 512 anyway).
I'll try to polish my hack a bit - seems like
it can help more people.
Regards
-- Stano
- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.rutgers.edu Please read the FAQ at http://www.tux.org/lkml/