From owner-freebsd-current Sat Mar 6 6:44:19 1999 Delivered-To: freebsd-current@freebsd.org Received: from verdi.nethelp.no (verdi.nethelp.no [158.36.41.162]) by hub.freebsd.org (Postfix) with SMTP id 0A65C15151 for ; Sat, 6 Mar 1999 06:44:10 -0800 (PST) (envelope-from sthaug@nethelp.no) Received: (qmail 6946 invoked by uid 1001); 6 Mar 1999 14:43:52 +0000 (GMT) To: alexlh@funk.org Cc: freebsd-current@freebsd.org Subject: Re: netscape trouebles From: sthaug@nethelp.no In-Reply-To: Your message of "Sat, 06 Mar 1999 14:14:34 +0100" References: <36E12A3A.294D4E2E@funk.org> X-Mailer: Mew version 1.05+ on Emacs 19.34.2 Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Date: Sat, 06 Mar 1999 15:43:52 +0100 Message-ID: <6944.920731432@verdi.nethelp.no> Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG > For quite some time now Netscape 4.5 has been very unstable on my > -current system. I've cvsup'ed and made world many times in the hope the > problem would go away. > > Today I decided to ktrace it, and see where it would stop. > > Of course it now refuses to crash. Even on java stuff that would crash > it _every_ time without the ktrace. > > Now I can start my netscape with "ktrace -f /dev/null netscape", and > it'll probably be happy, although this is less than a satisfactory > solution. > > I figure that the fact that it runs fine with the ktrace might mean > something significant, although I wouldn't know what. So if anyone has > an idea, I'd be delighted to hear about it. I've had an unstable Netscape ever since upgrading to 3.x. There was quite a bit of discussion about this around a month ago, but no firm conclusion was reached. For me, it happens with MOZILLA_NO_ASYNC_DNS turned on (ie. no separate DNS lookup processes) *and* I access a site where the corresponding name servers take a long time to answer. I found some more discussion about Netscape hanging in a Linux related Web page, and the author has also produced a (Linux specific) patch. I include the README file below. Sorry, no URL, but it's real easy to find the package (search for Netscape-pipepatch) with ftpsearch. Steinar Haug, Nethelp consulting, sthaug@nethelp.no ---------------------------------------------------------------------- The Netscape pipe overflow workaround ===================================== There is a known problem with most versions of Netscape currently in use, where the Netscape freezes when loading specific pages. The lockup is complete - there is no window refreshing and no reaction to the kill -TERM. The only way out is to kill the process with SIGKILL or from the window manager and to manually remove the lock file. The problem is timing-dependent - while most people seeing it can reproduce it using specific pages, these pages are different for different people. The cause of this problem is quite simple. On most (if not all Unixes) there is a limit on the pipe size and writing to a pipe will block, if the pipe is full. This limit is 4096 bytes on the Linux. The Netscape uses a pipe for some internal synchronisation and fails to take this into an account. When the pipe overflows, the Netscape locks up trying to write into the pipe and nobody reading it. The presented workaround is a side-effect of narrowing down this problem (the goal was to prove, if this is a kernel or application problem). It is NOT intended as a general solution to the problem (Netscape developers must fix it) and there is NO GUARANTEE that it doesn't break something else. However, the hack helped quite a lot of people and so I decided to publish it. The idea behind this hack is to insert a layer between Netscape and the libc, which catches the problematic pipe and fakes I/O operations that would otherwise cause the lock-up. Installation ============ First you must know what version of Netscape you are using - the keywords here are libc5 and glibc (aka libc6). This is not necessarily the library your distribution defaults to - it is perfectly possible to use libc5 Netscape on a glibc-based system. ldd $MOZILLA_HOME/netscape | grep libc.so will probably give an idea, but there can be broken installations of ldd giving questionable results (e.g. libc.so.5 => not found is a valid answer for a libc5 installation). Next edit the Makefile and check the LIBC and LIBDL variables. These should be OK for a glibc Netscape, you will need to change them for a libc5 one (the instructions for doing this is in the Makefile). Compile and install the hack (the default destination is /usr/local/lib): make make install Now the tricky part - you must set the LD_PRELOAD environment variable to point to your hack somewhere where only Netscape can see it. Generally you do this in some starting script for netscape. As the distributions vary here, you are basically on your own. The patch for Red Hat 5.2 is included (file starting.script.rh52.patch). End remarks =========== The workaround is (C) 1999 Stanislav Meduna. The use, modification and distribution is completely free. There is ABSOLUTELY NO WARRANTY and i will NOT support the workaround. There ARE known problems - it is not known, if they are caused by the hack or only exposed by using it - I will NOT try to fix them. Some of the discussion on this hack is included in the file Discussion. If you include the workaround in some distribution, I would like to hear about it. Stanislav Meduna stano@eunet.sk 30. 1. 1999 To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message