124103 - [FIX]infinite loop during page load

Status: RESOLVED FIXED

(Core :: XPCOM, defect, P1)

Description

[Mirko Zeibig]

From Bugzilla Helper:
User-Agent: Mozilla/5.0 (Windows; U; WinNT4.0; en-US; rv:0.9.8) Gecko/20020204
BuildID:    2002020406

If I try to load the page on URL http://support.bea.com/ the Browser trys to
load the page again and again with different parameters for the JSP behind the
URL. It works correct with Netscape 4.5 and older Mozillas

Reproducible: Always
Steps to Reproduce:
Go to http://support.bea.com/



Actual Results:  Mozilla trys to load the page again and again until You stop it.

Expected Results:  Display the page

Comment 1

[Karl Johan Kleist]

WFM. Build ID: 2002 02 04 09. Windows 2000.

Reporter: Please set severity level to "critical", and add the keyword "hang".

Comment 2

[Arthur]

Confirming on Linux 2002020611. Page has a refresh tag:
<meta HTTP-EQUIV=Refresh CONTENT="5999940; URL=/ ....

Comment 3

[Arthur]

Removing hang keyword as mozilla stays responsive and the stop button works.

Comment 4

[Boris Zbarsky [:bzbarsky]]

This would be because timers overflow.

Running this we take 5999940, convert it to ms, the convert to a PRIntervalTime
and add to now.  The result overflows PRUint32 and makes the timer fire
immediately.  Putting some printfs in nsTimerImpl::SetDelayInternal, I get:

  fprintf(stderr, "The delay: %u\n", PR_MillisecondsToInterval(mDelay));
  fprintf(stderr, "Now: %u\n", now);
  fprintf(stderr, "Time to fire: %u\n", mTimeout);

  The delay: 1704972704
  Now: 3813825852
  Time to fire: 1223831260

Note that "Time to fire" is before "Now".  We should guard against this...

Comment 5

[Boris Zbarsky [:bzbarsky]]

Attachment: Proposed patch

Comment 6

[Stuart Parmenter]

Comment on attachment 68484 [details] [diff] [review]
Proposed patch

r=pavlov

Comment 7

[Boris Zbarsky [:bzbarsky]]

taking bug

Comment 8

[meniscus]

I am able to load that URL successfully with 2002020406... not sure what could 
be different here as opposed to the author's configuration...

Comment 9

[Mirko Zeibig]

Did they change the page? It is now working for me too.

Comment 10

[Brendan Eich [:brendan]]

Comment on attachment 68484 [details] [diff] [review]
Proposed patch

Looks good.

Is there an evangelism issue here?  Does the site need to be advised not to set
so uselessly large a timeout?

/be

Comment 11

[Stuart Parmenter]

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

Comment 12

[Boris Zbarsky [:bzbarsky]]

I don't think this is worth evangelising -- we no longer fail on this site and
the evangelists' energy is better spent elsewhere...

Comment 13

[Stuart Parmenter]

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

Comment 14

[Boris Zbarsky [:bzbarsky]]

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

Comment 15

[gavin long]

> we no longer fail on this site

Re: comments in the duplicate 116361, this bug is tricky to pin down and
reproduce.  Sometimes it happens, sometimes it doesn't.  It's not even always
reproducible on the same page on the same instance of the browser.  So if the
problem just "went away", it doesn't mean it's not still lurking.

After all that, did the patch go in?  There's no indication one way or the other
above.  If so, has anyone tried testing before and after it went in?

Comment 16

[gavin long]

To partly answer my own question, Asa lists
(http://www.mozillazine.org/build_comments/) this bug as one of the checkins
made between 20020208 and 20020212.  I've tested builds from both dates with the
testcases on bug 116361: 0208=constant reloads  0212=no constant reloads.  So,
from here, it looks like Boris fixed it.  Yay Boris!

Comment 17

[Marc Boullet]

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

Comment 18

[gavin long]

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

Comment 19

[benc]

hey, bz, I know you can fixed bugs anywhere in the codebase, but we have this
thing called "component."  :)

Is this a networking bug (dunno where timers goes...)