Date: Fri, 02 Sep 2011 12:19:27 +0300 From: Andriy Gapon <avg@FreeBSD.org> To: Florian Smeets <flo@FreeBSD.org> Cc: gnome@FreeBSD.org, gecko@FreeBSD.org Subject: Re: firefox-6.0_1 spinning on a cpu Message-ID: <4E609F9F.6080208@FreeBSD.org> In-Reply-To: <4E5F7B22.40604@freebsd.org> References: <4E5F6753.3070402@FreeBSD.org> <4E5F737F.1070703@ksu.ru> <4E5F799C.7030509@FreeBSD.org> <4E5F7B22.40604@freebsd.org>
next in thread | previous in thread | raw e-mail | index | archive | help
[CC-ing gnome@ who is listed as the maintainer of devel/nspr] on 01/09/2011 15:31 Florian Smeets said the following: > On 01.09.2011 14:25, Andriy Gapon wrote: >> on 01/09/2011 14:58 Marat N.Afanasyev said the following: >>> I have a seamonkey with the same symptoms, from time to time it eats several >>> cores >>> of my CPU. >> >> Just a general note: at these level of diagnosing it is not possible to say if >> you >> see the same problem or not. That's why I tried to provide a little bit more >> detailed symptoms. >> > > Yes, it's a known problem, however we did not get any further on this topic, yet. > > We have a PR which was filed some time ago ports/156889 which describes a > similar problem. > > What i do know is that i can easily provoke it by going to > http://localhost:$port where $port is some random port where nothing listens. > > Adriy, I'm very happy that someone with kernel knowledge got interested in this ;) :-) I guess you had a reason for that. > P.S. I doubt it is fixed in 6.0.1 You are right about this. The following patch for devel/nspr port fixes the problem for me: --- mozilla/nsprpub/pr/src/pthreads/ptio.c.orig 2011-09-02 12:00:35.233509956 +0300 +++ mozilla/nsprpub/pr/src/pthreads/ptio.c 2011-09-02 12:00:39.987512769 +0300 @@ -1635,7 +1635,7 @@ static PRStatus pt_ConnectContinue( PR_SetError(PR_BAD_DESCRIPTOR_ERROR, 0); return PR_FAILURE; } - if ((out_flags & (PR_POLL_WRITE | PR_POLL_EXCEPT | PR_POLL_ERR)) == 0) + if ((out_flags & (PR_POLL_WRITE | PR_POLL_EXCEPT | PR_POLL_ERR | PR_POLL_HUP)) == 0) { PR_ASSERT(out_flags == 0); PR_SetError(PR_IN_PROGRESS_ERROR, 0); I am not actually sure if this patch is really needed, maybe it should only be a temporary FreeBSD-specific workaround. I need now to investigate if POLLHUP may be set by an OS on a socket that has never been connected (for which connect(2) failed). -- Andriy Gapon
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?4E609F9F.6080208>