Last Comment Bug 595823 - 100% cpu usage with host local address and failure to see RST's
: 100% cpu usage with host local address and failure to see RST's
Status: RESOLVED FIXED
:
Product: Core
Classification: Components
Component: General (show other bugs)
: 1.9.2 Branch
: x86 FreeBSD
: -- critical (vote)
: ---
Assigned To: Nobody; OK to take it and work on it
:
Mentors:
Depends on:
Blocks:
  Show dependency treegraph
 
Reported: 2010-09-13 03:54 PDT by Guido van Rooij
Modified: 2012-03-05 06:27 PST (History)
6 users (show)
See Also:
Crash Signature:
(edit)
QA Whiteboard:
Iteration: ---
Points: ---
Has Regression Range: ---
Has STR: ---


Attachments

Description Guido van Rooij 2010-09-13 03:54:50 PDT
User-Agent:       Mozilla/5.0 (X11; U; FreeBSD i386; en-US; rv:1.9.1.12) Gecko/20100908 Firefox/3.5.12
Build Identifier: Mozilla/5.0 (X11; U; FreeBSD i386; en-US; rv:1.9.1.12) Gecko/20100908 Firefox/3.5.12

When I try to connect to my own IP address (127.0.0.1 but also the address on my ethernet link), I can see in a tcpdump (-i lo0) that an RST is send in response to the SYN sent by Firefox. Yet, the tab continues to display "Loading" and in the bottom line it keeps saying "Connecting to ...". In the meantime, the CPU load goes to 100%. When connecting to an external address (on the same network), it also fails to see the RST, but now the CPU stays "normal". I don't see a timeout (waited for at last 2 minutes).
Connecting to an external system on a port with nothing listening gives the expected "Problem loading page" message.

Reproducible: Always

Steps to Reproduce:
1. Make sure there is no webserver listening on http://127.0.0.1:80
2. Open http://127.0.0.1:80
3. Start top in a seperate window and watch the CPU usage go up to 100%
4. See that Firefox does not notice there is no webserver (or any service) at that port
Comment 1 Guido van Rooij 2010-09-13 05:21:18 PDT
As I have no access to 3.6 (at the moment(, I just added the 3.5 branch (I;m using 3.5.12).
Comment 2 Matthias Versen [:Matti] 2010-09-13 09:09:13 PDT
It would be great if you test it again with Firefox4.0beta or a nightly build.
I can't see the problem on Seamonkey trunk on win32 or on FF3.6.9 in Ubuntu.
( I used :90 on my system because there is a webserver on port80 in my case).
Comment 3 Guido van Rooij 2010-09-14 00:12:41 PDT
(In reply to comment #2)
> It would be great if you test it again with Firefox4.0beta or a nightly build.
> I can't see the problem on Seamonkey trunk on win32 or on FF3.6.9 in Ubuntu.
> ( I used :90 on my system because there is a webserver on port80 in my case).

Sorry, I don't have access to Firefox4.0beta or a nightly build for FreeBSD.
Comment 4 Wayne Mery (:wsmwk, NI for questions) 2010-09-19 05:58:11 PDT
(In reply to comment #3)
> Sorry, I don't have access to Firefox4.0beta or a nightly build for FreeBSD.

no v3.6?
Comment 5 Guido van Rooij 2010-09-23 13:19:25 PDT
Firefox 3.6.10 behaves the same as 3.5.9 on my system
Comment 6 Dirk Meyer 2010-12-06 04:14:41 PST
firefox-3.6.12 on FreeBSD 8.1 i386 still have this Problem.

netstat shows a handfull connections.

trying to attach with truss, i see a lot
of calls retuning "socket not connected errors".

It might be a problem of an library firefox uses.
Comment 7 Dirk Meyer 2011-03-06 04:16:33 PST
The problem still bites:

FreeBSD 8.2-RERELEASE, i386

firefox-3.6.13,1:
Dependency: pkg-config-0.25_1
Dependency: xproto-7.0.16
Dependency: libX11-1.3.3_1,1
Dependency: libXext-1.1.1,1
Dependency: libXinerama-1.1,1
Dependency: libXi-1.3,1
Dependency: libICE-1.0.6,1
Dependency: libSM-1.1.1_3,1
Dependency: libXt-1.0.7
Dependency: nspr-4.8.6
Dependency: glib-2.26.1_1
Dependency: gio-fam-backend-2.26.1
Dependency: libIDL-0.8.14_1
Dependency: pango-1.28.3
Dependency: desktop-file-utils-0.15_2
Dependency: dbus-glib-0.88
Dependency: libiconv-1.13.1_1
Dependency: zip-3.0
Dependency: atk-1.32.0
Dependency: gtk-2.22.1_1
Dependency: libnotify-0.5.2
Comment 8 Dirk Meyer 2011-04-25 12:10:18 PDT
Same Problem with Firefox-4.0 with all extensions disabled.
FreeBSD 8.2 on i386 and amd64
Comment 9 Dirk Meyer 2011-11-02 11:54:17 PDT
Patch is availible in:
https://bugzilla.mozilla.org/show_bug.cgi?id=684758
Comment 10 Phoenix 2012-03-05 06:27:38 PST
Set fixed according to Comment 9

Note You need to log in before you can comment on or make changes to this bug.