From owner-freebsd-mozilla Tue Sep 14 22:46:13 1999 Delivered-To: freebsd-mozilla@freebsd.org Received: from sparkle.Generation.NET (sparkle.Generation.NET [205.205.119.4]) by hub.freebsd.org (Postfix) with ESMTP id BA52C1548A for ; Tue, 14 Sep 1999 22:46:09 -0700 (PDT) (envelope-from gsstark@mit.edu) Received: from x2-513.mtl.Generation.NET (brnstndkramden.acf.nyu.edu@x2-513.mtl.Generation.NET [209.205.11.168]) by sparkle.Generation.NET (8.9.3/8.9.3) with SMTP id BAA22529; Wed, 15 Sep 1999 01:46:14 -0400 (EDT) To: Terry Lambert Cc: gsstark@mit.edu (Greg Stark), denis@acacia.cts.ucla.edu, mozilla@freebsd.org Subject: Re: Communicator 4.5: "Xlib: Unexpected async reply" msg flood! References: <199909150357.UAA16678@usr06.primenet.com> In-Reply-To: Terry Lambert's message of "Wed, 15 Sep 1999 03:57:01 +0000 (GMT)" From: Greg Stark Organization: People's Front Against MWM Date: 15 Sep 1999 01:45:58 -0400 Message-ID: <877lls682x.fsf@x2-513.mtl.Generation.NET> Lines: 22 User-Agent: Gnus/5.070095 (Pterodactyl Gnus v0.95) Emacs/20.3 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-freebsd-mozilla@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG > The serialization soloution was arrived at by me, after observing > the problem and non-problem platforms, and taking into account my > detailed knowledge of threads implemetnations on Solaris, Linux, > Windows 98, Windows NT, Macintosh, and FreeBSD. So in your case you're fairly certain it was the GIF decoder that was buggy? Did you have a particular test page that could reliably crash communicator? This would be especially good if it reliably triggered the sequence errors. I'm certain the Linux version and fairly certain that the other versions of communicator do _not_ use the native OS thread implementation. They use the built in user-space NSPR thread implementation. Which I think is supposed to use a simple FIFO scheduler like you describe. My hunch on the bug is that Java's run-time sets up the signal handlers one way and the rest of Netscape expects them to be set up a different way. And the net result is that some call that doesn't expect to be interrupted gets a SIGALRM and some X library call is preempted when it shouldn't be. -- greg To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-mozilla" in the body of the message