Messages in this thread | | | Subject | Re: Netscape broken with 2.2.0-pre7 | From | Andi Kleen <> | Date | 17 Jan 1999 17:09:51 +0100 |
| |
[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/
| |