Conn: alert dialog consumes 100% cpu if network is down

VERIFIED FIXED in mozilla0.9.1

Status

()

defect
P3
normal
VERIFIED FIXED
19 years ago
18 years ago

People

(Reporter: xk, Assigned: darin.moz)

Tracking

Trunk
mozilla0.9.1
x86
Linux
Points:
---
Dependency tree / graph

Firefox Tracking Flags

(Not tracked)

Details

Attachments

(3 attachments)

(Reporter)

Description

19 years ago
From Bugzilla Helper:
User-Agent: Mozilla/5.0 (X11; U; Linux 2.2.17 i686; en-US; m18) Gecko/20001015
BuildID:    2000101521

If disconnected from the 'net (eg: not online with dialup modem,etc), trying any
URL will bring up an alert dialog which says "can't resolve blah.blah" and then
consomes 100% CPU until the dialog is closed.

Reproducible: Always
Steps to Reproduce:
1. disconnect internet connectivity
2. launch mozilla
3. type in any URL in location box, press enter.
   (I did "about:" then selected the mozilla icon)
4. check CPU usage.

Actual Results:
  alert dialog should appear but should not consume 100% CPU.


Expected Results:
  ~0% CPU usage.

Additional Information:
  Happens with build 2000101521 and 20001009
  Happens with and without local squid proxy daemon.

Comment 1

19 years ago
*** Bug 57100 has been marked as a duplicate of this bug. ***

Comment 2

19 years ago
Confirming bug. I see this happen with 2000101708
Also: Immediately after dismissing the box, X briefly sucks 90% CPU before
things stabilize. Why a tiny dialog-box can use that much CPU is...odd.
Status: UNCONFIRMED → NEW
Ever confirmed: true
cc: gagan

gagan - is this a networking issue?

Comment 4

19 years ago
could be. Our lookups are not async on linux. (as yet... see bug 10733)

Comment 5

19 years ago
over to networking.
Assignee: asa → gagan
Component: Browser-General → Networking
QA Contact: doronr → tever
*** Bug 59199 has been marked as a duplicate of this bug. ***

Comment 7

19 years ago
It seems to me that all the small dialogs in mozilla consume 100% CPU. In
adittion, it locks mozilla up (ie. you can't use any other mozilla-window) until
you press "ok".  
*** Bug 60135 has been marked as a duplicate of this bug. ***

Comment 9

19 years ago
There is an interesting observation in bug 61590.
Dup?
(Assignee)

Comment 10

19 years ago
->me
Assignee: gagan → darin
(Assignee)

Updated

19 years ago
Blocks: 61683
(Assignee)

Updated

19 years ago
Blocks: 61689

Comment 11

19 years ago
As observed through noting duplicates, spinning occurs for all
alert windows.  However, not all alert windows behave in the
same way.  The DNS alert merely consumes all of the CPU.  The
timed out alert and at least one of the security alerts cause
the following (approximate) load distribution:

  58% mozilla-bin
  24% X
  18% klipper (kde clip board)

The alert window can kill long-running downloads.  (I.e., when
I'm downloading 100MB at slow rates and go away, the failure of
an ad's DNS lookup in a reloading frame can kill the download.)

I tried to trace this bug, but I couldn't get gdb to go near the
call to prompter->Alert() and I couldn't find the implementation
of the Alert() method.
*** Bug 65255 has been marked as a duplicate of this bug. ***
(Assignee)

Comment 13

19 years ago
it seems like mozilla is getting stuck inside the guts of glib's
g_main_iteration().  attaching a stack trace...
(Assignee)

Comment 14

19 years ago
*** Bug 67043 has been marked as a duplicate of this bug. ***
(Assignee)

Updated

18 years ago
Target Milestone: --- → Future

Comment 16

18 years ago
In addition to consuming CPU, it also consumes memory.
After about 18 hour of an error dialog being up, mozilla-bin
has a size of 300M as reported by top.

Comment 17

18 years ago
*** Bug 75439 has been marked as a duplicate of this bug. ***
*** Bug 76349 has been marked as a duplicate of this bug. ***

Comment 19

18 years ago
Should this be marked as a mostfreq? Between the number of duplicate assigned to
this one and the number assigned to it's duplicates, it's getting pretty popular
:-) (e.g. bug 61590 alone has 3 duplicates...).

(Assignee)

Updated

18 years ago
Keywords: mostfreq, nsbeta1
Target Milestone: Future → mozilla0.9.1

Comment 20

18 years ago
The previous stack trace misses the crucial part of the problem which is that 
PL_ProcessPendingEvents is being called recursively. The routine is coded to 
detect that it is already being run and in that case it returns without dealing 
with the notification that caused it to be called again in the first place.  
This leads to it being called repeatedly.

Adding a call to _pl_AcknowledgeNativeNotify(self) before the first return
statement eliminates the CPU munching.  See following patch.
Keywords: review
*** Bug 78488 has been marked as a duplicate of this bug. ***
(Assignee)

Comment 24

18 years ago
neeti: could you help track down the source of this loop?  thanks!

Comment 25

18 years ago
I am going to look into this...

Comment 26

18 years ago
I've just started to use 0.9 with Steve Ratcliffe's
patch applied.  This fixes the problem.  Not only
have I not observed any bad side effects, I suspect
that it has made Mozilla run faster.

This bug is really nasty on multi-user machines.  I
hope that the patch is checked and applied as soon
as possible and makes it into 0.91.

Comment 27

18 years ago
The patch is good. It restores the fix for this problem that was checked in in 
rev 1.2 but was clumsily backed out in rev 1.11. The original fix was good and it 
was wrong to back it out. r=danm. Check it in.
(Assignee)

Comment 28

18 years ago
fix checked in
Status: NEW → RESOLVED
Last Resolved: 18 years ago
Resolution: --- → FIXED
Summary: alert dialog consumes 100% cpu if network is down

Comment 29

18 years ago
Restoring summary that was lost when the bug was marked FIXED.
Summary: alert dialog consumes 100% cpu if network is down
*** Bug 83809 has been marked as a duplicate of this bug. ***

Comment 31

18 years ago
verified - Top is showing that nothing is pegging cpu 
Linux rh6 2001061308
Status: RESOLVED → VERIFIED

Comment 32

18 years ago
+makingtest - need to read dupes and add this test case.
Keywords: makingtest
Summary: alert dialog consumes 100% cpu if network is down → Conn: alert dialog consumes 100% cpu if network is down
*** Bug 61590 has been marked as a duplicate of this bug. ***
You need to log in before you can comment on or make changes to this bug.