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

Status: VERIFIED FIXED

(Core :: Networking, defect, P3)

Description

[xk]

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

[R.K.Aa.]

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

Comment 2

[R.K.Aa.]

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.

Comment 3

[Doron Rosenberg (IBM)]

cc: gagan

gagan - is this a networking issue?

Comment 4

[Gagan]

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

Comment 5

[Asa Dotzler [:asa]]

over to networking.

Comment 6

[Matthias Versen [:Matti]]

*** Bug 59199 has been marked as a duplicate of this bug. ***

Comment 7

[hennikul]

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".  

Comment 8

[Matthias Versen [:Matti]]

*** Bug 60135 has been marked as a duplicate of this bug. ***

Comment 9

[R.K.Aa.]

There is an interesting observation in bug 61590.
Dup?

Comment 10

[Darin Fisher]

->me

Comment 11

[mlvanbie]

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.

Comment 12

[Matthias Versen [:Matti]]

*** Bug 65255 has been marked as a duplicate of this bug. ***

Comment 13

[Darin Fisher]

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

Comment 14

[Darin Fisher]

Attachment: stack trace (snapshot of endless loop)

Comment 15

[Matthias Versen [:Matti]]

*** Bug 67043 has been marked as a duplicate of this bug. ***

Comment 16

[Tony.Lill]

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

[R.K.Aa.]

*** Bug 75439 has been marked as a duplicate of this bug. ***

Comment 18

[Matthias Versen [:Matti]]

*** Bug 76349 has been marked as a duplicate of this bug. ***

Comment 19

[Len Trigg]

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...).

Comment 20

[Steve Ratcliffe]

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.

Comment 21

[Steve Ratcliffe]

Attachment: Patch to prevent repeated notifications

Comment 22

[Daniel Mario Vega (Restore MNG Support --> #18574)]

Attachment: HTML Test Case

Comment 23

[Matthias Versen [:Matti]]

*** Bug 78488 has been marked as a duplicate of this bug. ***

Comment 24

[Darin Fisher]

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

Comment 25

[Gagan]

I am going to look into this...

Comment 26

[mlvanbie]

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

[Dan M]

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.

Comment 28

[Darin Fisher]

fix checked in

Comment 29

[Daniel Bratell]

Restoring summary that was lost when the bug was marked FIXED.

Comment 30

[Matthias Versen [:Matti]]

*** Bug 83809 has been marked as a duplicate of this bug. ***

Comment 31

[Tom Everingham]

verified - Top is showing that nothing is pegging cpu 
Linux rh6 2001061308

Comment 32

[benc]

+makingtest - need to read dupes and add this test case.

Comment 33

[Boris Zbarsky [:bzbarsky]]

*** Bug 61590 has been marked as a duplicate of this bug. ***