Closed Bug 136958 Opened 22 years ago Closed 22 years ago

META HTTP-EQUIV="refresh" stops working after a while

Categories

(Core :: XPCOM, defect, P1)

defect

Tracking

()

RESOLVED FIXED

People

(Reporter: ulrichsk, Assigned: dougt)

Details

Attachments

(2 files)

The refresh stops working ervery 60 minutes after the browsert was started.
The following HTML-Code illustrates the problem:
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN" >
<html>
<head>
<title></title>
<META HTTP-EQUIV="refresh" CONTENT="60; url=file:///F:/y.html">
</head>
<script>
var mow = new Date();
document.write('Status
('+mow.getHours()+':'+mow.getMinutes()+':'+mow.getSeconds()+'):<br>');
</script>
</body>
</html>
i forgot to mention, that if i have Cinema/2 (TV-Program) running, refresh
doesnt work at all.
docshell handles refresh, IIRC
Assignee: Matti → adamlock
Component: Browser-General → Embedding: Docshell
QA Contact: imajes-qa → adamlock
I don't see this problem. Mine ran for 12 hours. There must be something else 
stopping the timers.

Please check on a current build.
Version 0.9.8 and perhaps 0.9.7 had this problem on my system too.
Seems that other applications affect the timer behavior (see my 2. comment
regarding Cinema/2).
Some idea how i can start some investigations?
For reference, the refresh mechanism in docshell is here:

http://lxr.mozilla.org/seamonkey/source/docshell/base/nsDocShell.cpp#3423

I have set my timer running and I will report the results in an hour. Note that
I had to change the original HTML because it was malformed (no <BODY> tag). Also
note that content="60" means 60 seconds, not 60 minutes, which means it should
refresh 60 times before exhibiting the reported problem.
Marking WORKSFORME.

I left the timer running 90 minutes and timers were still working correctly at
the end of that time. For reference, by HTML was this (lines in JS may wrap)

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN" >
<html>
<head>
<title></title>
<meta HTTP-EQUIV="refresh" CONTENT="60; url=file:///c:/m/test/136958.html">
<body>
<script>
var mow = new Date();
document.write('Status('+mow.getHours()+':'+mow.getMinutes()+':'+mow.getSeconds()+'):<br>');
</script>
</head>
</body>
</html>

Status: UNCONFIRMED → RESOLVED
Closed: 22 years ago
Resolution: --- → WORKSFORME
Please note I tested on Win32. I do not have any way to test OS/2. If you
believe this is a problem with timers on OS/2 then it may be best to reopen this
bug, but it will be reassigned to the appropriate maintainers..
Thanks for the link and comments.
It seems that this bug  caused by a problem with the OS/2 timers, so the OS/2
experts should have a look at this.
So i will reopen this bug. But  how  can i  assign it to the appropriate OS/2
maintainers?

You are right, the <body>--tag was missing in this html-code.
Yes, 60 seconds refresh time is that what i meant. After 60 or 59  refreshs,
refreshing stops. You can start it again by reloading (F5) the page..
It is important to emphasize that the refresh stops working ervery 60 minutes
after the BROWSER was started, i.e. with a browser start at 8:17  the refresh
will stop working at 9:17, 10:17, 11:17, ...
Status: RESOLVED → UNCONFIRMED
Resolution: WORKSFORME → ---
Reassign
Component: Embedding: Docshell → NSPR
Product: Browser → NSPR
Reassigning to NSPR. Could be a problem with timers on OS/2. 
Assignee: adamlock → wtc
QA Contact: adamlock → wtc
Michael, could you take a look at this bug?  Thanks.
There are no OS/2 specific timers.

All the timer code is cross platform now.

I tried this on my machine and was able to run for quite a while.

Does anyone know if there is NSPR logging for the timers?


This should definitely be in the browser boat.

I can get it to fail.

when it fails, I see tons of extra timer creations in the log after the 
failure.

This looks like an XP timer failure.

I need some advice on how to try to track it down.

It happens after about 20 minutes for me.

6[2d3e08]: waiting for 3599676
6[2d3e08]: waiting for 3599994
0[2a4220]: nsComponentManager: 
CreateInstanceByContractID(@mozilla.org/timer;1) succeeded
6[2d3e08]: waiting for 492
0[2a4220]: nsComponentManager: 
CreateInstance({6049b261-c1e6-11d1-a827-0040959a28c9}) succeeded
0[2a4220]: $$$ processing event
0[2a4220]: $$$ done processing event
0[2a4220]: nsComponentManager: 
CreateInstanceByContractID(@mozilla.org/timer;1) succeeded
6[2d3e08]: waiting for 492
0[2a4220]: nsComponentManager: 
CreateInstanceByContractID(@mozilla.org/timer;1) succeeded
6[2d3e08]: waiting for 492
0[2a4220]: nsComponentManager: 
CreateInstanceByContractID(@mozilla.org/timer;1) succeeded
6[2d3e08]: waiting for 492
0[2a4220]: nsComponentManager: 
CreateInstanceByContractID(@mozilla.org/timer;1) succeeded
6[2d3e08]: waiting for 492
0[2a4220]: nsComponentManager: 
CreateInstanceByContractID(@mozilla.org/timer;1) succeeded
6[2d3e08]: waiting for 492
0[2a4220]: nsComponentManager: 
CreateInstanceByContractID(@mozilla.org/timer;1) succeeded
6[2d3e08]: waiting for 492
0[2a4220]: nsComponentManager: 
CreateInstanceByContractID(@mozilla.org/timer;1) succeeded
6[2d3e08]: waiting for 492
0[2a4220]: nsComponentManager: 
CreateInstanceByContractID(@mozilla.org/timer;1) succeeded
6[2d3e08]: waiting for 492
0[2a4220]: nsComponentManager: 
CreateInstanceByContractID(@mozilla.org/timer;1) succeeded
6[2d3e08]: waiting for 492
0[2a4220]: nsComponentManager: 
CreateInstanceByContractID(@mozilla.org/timer;1) succeeded
6[2d3e08]: waiting for 492
0[2a4220]: nsComponentManager: 
CreateInstanceByContractID(@mozilla.org/timer;1) succeeded
6[2d3e08]: waiting for 492
0[2a4220]: $$$ processing event
0[2a4220]: $$$ done processing event
0[2a4220]: nsComponentManager: 
CreateInstance({6049b261-c1e6-11d1-a827-0040959a28c9}) succeeded
6[2d3e08]: Timer thread woke up -6ms from when it was supposed to
6[2d3e08]: waiting for 3392821
0[2a4220]: $$$ processing event
0[2a4220]: [this=d436b0] time between PostTimerEvent() and Fire(): 0ms
0[2a4220]: [this=d436b0] expected delay time  500ms
0[2a4220]: [this=d436b0] actual delay time    494ms
0[2a4220]: [this=d436b0] (mType is 0)       -------
0[2a4220]: [this=d436b0]     delta             -6ms
0[2a4220]: UpdateFilter: smoothSlack = -375.3, filterLength = 20
0[2a4220]: nsComponentManager: 
CreateInstanceByContractID(@mozilla.org/timer;1) succeeded
0[2a4220]: [this=d436b0] Took 5ms to fire timer callback
0[2a4220]: $$$ done processing event
6[2d3e08]: waiting for 4992
0[2a4220]: nsComponentManager: 
CreateInstanceByContractID(@mozilla.org/timer;1) succeeded
6[2d3e08]: waiting for 492
0[2a4220]: nsComponentManager: 
CreateInstanceByContractID(@mozilla.org/timer;1) succeeded
6[2d3e08]: waiting for 492
0[2a4220]: nsComponentManager: 
CreateInstanceByContractID(@mozilla.org/timer;1) succeeded
6[2d3e08]: waiting for 492
0[2a4220]: nsComponentManager: 
CreateInstanceByContractID(@mozilla.org/timer;1) succeeded
6[2d3e08]: waiting for 492
0[2a4220]: nsComponentManager: 
CreateInstanceByContractID(@mozilla.org/timer;1) succeeded
6[2d3e08]: waiting for 492
0[2a4220]: nsComponentManager: 
CreateInstanceByContractID(@mozilla.org/timer;1) succeeded
6[2d3e08]: waiting for 492
0[2a4220]: nsComponentManager: 
CreateInstanceByContractID(@mozilla.org/timer;1) succeeded
6[2d3e08]: waiting for 492
0[2a4220]: nsComponentManager: 
CreateInstanceByContractID(@mozilla.org/timer;1) succeeded
6[2d3e08]: waiting for 492
0[2a4220]: nsComponentManager: 
CreateInstanceByContractID(@mozilla.org/timer;1) succeeded
6[2d3e08]: waiting for 492
0[2a4220]: nsComponentManager: 
CreateInstanceByContractID(@mozilla.org/timer;1) succeeded
6[2d3e08]: waiting for 492
0[2a4220]: nsComponentManager: 
CreateInstanceByContractID(@mozilla.org/timer;1) succeeded
6[2d3e08]: waiting for 492
0[2a4220]: nsComponentManager: 
CreateInstanceByContractID(@mozilla.org/timer;1) succeeded
6[2d3e08]: waiting for 492
0[2a4220]: nsComponentManager: 
CreateInstanceByContractID(@mozilla.org/timer;1) succeeded
0[2a4220]: nsComponentManager: 
CreateInstanceByContractID(@mozilla.org/timer;1) succeeded
0[2a4220]: nsComponentManager: 
CreateInstance({6049b261-c1e6-11d1-a827-0040959a28c9}) succeeded
0[2a4220]: 211842 [this=c752f8] imgRequest::GetImage
0[2a4220]: $$$ processing event
0[2a4220]: $$$ done processing event
0[2a4220]: nsComponentManager: 
CreateInstance({6049b261-c1e6-11d1-a827-0040959a28c9}) succeeded
0[2a4220]: 211866 [this=c752f8] imgRequest::GetImage
0[2a4220]: $$$ processing event
0[2a4220]: $$$ done processing event
0[2a4220]: nsComponentManager: 
CreateInstanceByContractID(@mozilla.org/timer;1) succeeded
0[2a4220]: nsComponentManager: 
CreateInstanceByContractID(@mozilla.org/timer;1) succeeded
0[2a4220]: nsComponentManager: 
CreateInstanceByContractID(@mozilla.org/timer;1) succeeded
0[2a4220]: $$$ processing event

Assignee: wtc → dougt
Status: UNCONFIRMED → NEW
Component: NSPR → XPCOM
Ever confirmed: true
Product: NSPR → Browser
QA Contact: wtc → scc
Stuart,

Any advice on how to track this one?

See the last comment.

Thanks
to pavlov for investigation.  
Assignee: dougt → pavlov
More Info.

After a while, the Notify in docshell is just simply not happening. I'm still 
investigating if the timer is simply not kicking.
This is definitely looking like an XP bug.

The timer is being added to the timer thread, but the Run in TimerThread is 
never executing the timer.

I'm still looking to figure out why.
There is a major timer bug here and I need some help here.

Can someone please explain why the only timer ever accessed in ::Run is 
mTimers[0]?

This means that if by some strange coincidence, a timer never drops down to 
position 0, it never gets executed. That is the issue here.

I'm attaching a large log that shows this.
Severity: normal → major
Attached file Log of problem
OK, the best way to look at this log is to search on refresh.html.

Before the first refresh.html, notice a DOCSHELL timer created for 60000 and
that timer inserted into the timerthread list. You can then see that it is in
the list.
Farther down you can see a PLEvent created for that timer.

Now keep searching on refresh.html until you get to the last one. Again, you
see the DOCSHELL timer created and the timer put on the list.

If you look at the lists of timers following the last refresh.html, you can see
that the timer is in the timer list but it is never executed because it never
moves to mTimers[0].
I just got this to happen on Windows after five hours.

Upping severity.

Losing timers is a big deal.
Severity: major → critical
OS: OS/2 → All
Hardware: PC → All
Summary: META HTTP-EQUIV="refresh" stops working every 60 minutes (Mozilla 0.9.9 Build ID: 2002031114) → META HTTP-EQUIV="refresh" stops working after a while
OK, I have tons more info here.

I'm moving the bug to NSPR because I am going to use it to change the OS/2 timer
code.

But there is a major cross-platform bug here.

PR_IntervalNow is being used for timers, but it wraps. So there are cases where
timers don't fire if they happen around the wrap.

OS/2 was seeing the problem sooner because of a crappy timer implementation.
Component: XPCOM → NSPR
Product: Browser → NSPR
Target Milestone: --- → 4.1.2
Version: other → 4.1.2
Attachment coming up
Assignee: pavlov → wtc
OS: All → OS/2
QA Contact: scc → wtc
Hardware: All → PC
I'm removing our attempt to do high resolution timers on OS/2 and just
switching to the default millisecond timer.

If someone can show me a place where Mozilla genuinely needs macrosecond or
nanosecond resolution, we will look at putting it back, but this code is simply
wrong.

Using the millisecond timer is much much safer
mkaply: I'm sure no one needs < 10ms resolution, but did you mean to say you saw
Windows wrapping?  Do we need another bug with a different OS setting?

/be
I ran this testcase last night and definitely saw Windows stop similar to OS/2.

I believe the case is rare, but can happen.

Per the documentation on PR_TimerInterval, it does wrap, so if a timer happens 
to be scheduled just past the wrap, I think it will be missed.

I'm going to talk to pav about it when he gets back on Monday.

Comment on attachment 80062 [details] [diff] [review]
Remove high performance timers from OS/2

r=cls
Attachment #80062 - Flags: review+
Taking as wtc's on vacation.  We're going to need this on the branch as well.
Assignee: wtc → seawood
Keywords: adt1.0.0, mozilla1.0
Priority: -- → P1
Target Milestone: 4.1.2 → 4.2.1
I'll take the branch side since I can actually check it in then (assuming I can 
actually get a response from drivers for approval)
The patch has been checked in on the client branch & the NSPR trunk.

Checking in nsprpub/pr/src/md/os2/os2inrval.c;
/cvsroot/mozilla/nsprpub/pr/src/md/os2/os2inrval.c,v  <--  os2inrval.c
new revision: 3.7; previous revision: 3.6
done

Checking in nsprpub/pr/src/md/os2/os2inrval.c;
/cvsroot/mozilla/nsprpub/pr/src/md/os2/os2inrval.c,v  <--  os2inrval.c
new revision: 3.6.2.1; previous revision: 3.6
done
Comment on attachment 80062 [details] [diff] [review]
Remove high performance timers from OS/2

a=scc for checkin to the mozilla 1.0 branch
Attachment #80062 - Flags: approval+
Fix checked in
Status: NEW → RESOLVED
Closed: 22 years ago22 years ago
Resolution: --- → FIXED
removing adt1.0.0.  
Keywords: adt1.0.0
I got email that this is working.
Status: RESOLVED → VERIFIED
This is a cross-platform bug. The Windows NSPR code is still using the high-res
timer, which has the maximum resolution supported by NSPR interval timers, and
will therefore wrap at 5 hours.

This fix was only fixed on OS/2, by lowering the resolution of the timer in the
OS/2 NSPR interval implementation. However, there are other NSPR applications
than Mozilla that need high-resolution timing. I have opened a separate bug on
this, 164841.

As of today, this bug still occurs on Windows since NSPR on Windows has
high-resolution timing. It will happen on any platform that has the maximum NSPR
timer resolution.

The bug is in in the XP browser code, and that's where it should be corrected.
Whenever an interval may be longer than 5 hours, the browser must use PRTime and
PR_Now(), not PRIntervalTime / PR_IntervalNow().
Status: VERIFIED → REOPENED
OS: OS/2 → All
Hardware: PC → All
Resolution: FIXED → ---
Actually I believe the wrapping in the XP timer code was fixed.
Over to Pavlov for verification that the XP timer bug was fixed.
 
Assignee: seawood → pavlov
Status: REOPENED → NEW
Component: NSPR → XPCOM
Product: NSPR → Browser
Target Milestone: 4.2.1 → ---
Version: 4.1.2 → other
I believe that

http://bugzilla.mozilla.org/show_bug.cgi?id=138791 nsTimer does not handle
interval rollover

Fixed this

pavlov -> dougt
Assignee: pavlov → dougt
looks like brendan fixed this.  Brendan, confirm please.
I can confirm that bug 138791 is fixed, if that's what you want.  Doug, if you
have tested this and it worksforyou, please close and I'll mark VERIFIED.

/be
ran the test case here for the last 8 hours and it is still refreshing.
Status: NEW → RESOLVED
Closed: 22 years ago22 years ago
Resolution: --- → FIXED
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Created:
Updated:
Size: