lkml.org 
[lkml]   [1999]   [Jan]   [17]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
SubjectRe: Netscape broken with 2.2.0-pre7
From
Date
[cc'ed to mozilla's nspr mailing list. it may not be 100% on-topic there,
because the bug has only be shown with ns4.x so far, but there are good
chances that mozilla has similar problems, so I hope it is ok]

In article <19990116204908.A1473@tantalophile.demon.co.uk>,
lkd@tantalophile.demon.co.uk (Jamie Lokier) writes:
> On Fri, Jan 15, 1999 at 09:35:46PM -0600, Joseph Anthony wrote:
>> Every thing is ok with me (pre7) Netscape 4.08
>> Debian 2.0

> I have checked, the problem is still present with Netscape 4.08.
> (netscape-navigator-4.08-1.i386.rpm as distributed by Red Hat).

I have the same problems with navigator 4.5/glibc with 2.2.0pre7.

> Further tracing reveals that the regular, high speed SIGALRM signals are
> quite normal -- netscape receives them all the time. It sets a timer
> requesting them every 50ms, though it only receives them every 70ms.

I looked at the Mozilla nspr source, and it seems that SIGALRM handler
is used to schedule the NSPR user level threads.

> Netscape uses a pipe to queue single-byte tokens. The same process
> reads and writes the pipe. In normal operation, only a few tokens go
> into the pipe (about 1-40), and then the pipe is emptied (a byte at a
> time).

In the nspr3.0 sources all pipe reading seems to be protected by
if (_PR_IS_NATIVE_THREAD_SUPPORTED()) .., but maybe that is different
in the NSPR version netscape 4.x uses.


> Netscape keeps going through the cycle of writing tokens to the pipe in
> bursts, then flushing the lot. This appears to be normal, as it also
> does lots of other things in between bursts.

> With kernel pre7, once I start downloading a file, this cycle keep going
> but the number and size of write bursts before the read burst increases
> a little at each cycle, until eventually so many tokens are written that
> the pipe fills and the process blocks.

> This is when Netscape stops working -- when the pipe fills up.

> Netscape doesn't set the pipe to be non-blocking or anything. It could
> use those SIGALRM calls to switch to the reading thread or whatever (who
> knows what goes on in there), but it doesn't.

At least the nspr 3.0 version I am looking at sets the pipe to non
blocking (in pr/src/md/unix/unix.c:_MD_InitCPUS())

> This looks like a Netscape bug. However it doesn't happen (for me) with
> 2.2.0-pre4. Someone else reported that it does happen for them with
> other than pre7, and pre7 has fixed it for them. A few other people
> haven't noticed the problem; a few more have seen it with 2.0.36.

A binary search to find the exact version where it broke would be
very helpful.

> The bug occurs much less often when I run netscape under `strace -tt -o
> log', though it still occurs eventually. `strace -o log' is not so
> effective. The is also some interaction with the X server, because if I
> don't move the mouse (at all) or type anything after Netscape locks, it
> recovers after about a second.

Not surprising, strace changes signal timing.

-Andi

-
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/

\
 
 \ /
  Last update: 2005-03-22 13:49    [W:0.650 / U:0.016 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site