Closed Bug 615858 Opened 14 years ago Closed 12 years ago

Intermittent 472237-1.html | Test timed out

Categories

(Core :: CSS Parsing and Computation, defect)

Product:
Core
Component:
CSS Parsing and Computation
Platform:
All
macOS
Type:
defect
Priority:
Not set
Severity:
normal

Tracking

()

Status:
RESOLVED WORKSFORME

People

(Reporter: mstange, Unassigned)

References

Details

(Keywords: intermittent-failure) 

http://tinderbox.mozilla.org/showlog.cgi?log=Firefox/1291213775.1291215035.26098.gz
Rev3 MacOSX Leopard 10.5.8 mozilla-central debug test crashtest on 2010/12/01 06:29:35
s: talos-r3-leopard-020

REFTEST TEST-UNEXPECTED-FAIL | http://localhost:4444/1291214003833/3/crashtests/472237-1.html | timed out waiting for onload to fire
TEST-UNEXPECTED-FAIL | Shutdown | application timed out after 330 seconds with no output
Tip: It isn't a random orange if it happens every run.

Should be fixed by backout http://hg.mozilla.org/mozilla-central/rev/1b4041e3c177
No longer blocks: 438871, 472237
Status: NEW → RESOLVED
Closed: 14 years ago
Resolution: --- → FIXED
Whiteboard: [orange]
That was a very valuable tip, thanks!

Honestly, somehow I thought it had already happened before my push, but I hadn't realized that that was a different crashtest timeout.
(In reply to comment #6)
> That was a very valuable tip, thanks!
> 
> Honestly, somehow I thought it had already happened before my push, but I
> hadn't realized that that was a different crashtest timeout.

Well the good news is you may have been right all along, this is still showing up after the backout. The bad news is it is still (nearly) permanent orange and I have no clue why at the moment.
Blocks: 438871
Status: RESOLVED → REOPENED
Resolution: FIXED → ---
Whiteboard: [orange]
The current state is this:

This problem is causing crashtests on Leopard to hang on shutdown and on debug builds to also timeout during 472237-1.html
We've re-run crashtests on old supposedly good builds and they are failing too. Crashtest runs on the try server are also failing, even when the try pushes were based on day old m-c changesets.
Crashtests seem to have started failing at 5am.
bhearsum tried setting the date back to yesterday on a slave and running manually and was still seeing a hang.
The shutdown timeout was happening because of bug 616088.  I filed and fixed bug 616085, so I'm morphing this bug to only cover the test failure.
Summary: Intermittent 472237-1.html | Test timed out followed by shutdown timeout → Intermittent 472237-1.html | Test timed out
Depends on: 616088
The test timeout didn't happen before the DNS issues and I gather hasn't happened since. Any reason to suspect it is a different issue?
(In reply to comment #11)
> The test timeout didn't happen before the DNS issues and I gather hasn't
> happened since. Any reason to suspect it is a different issue?

Can you explain why the the DNS failure should result in this test timing out?  Cause I sure can't!
It wouldn't surprise me at all if 'localhost' requires waiting for a DNS lookup to complete.  (I know that when we do example.com in mochitest, through the PAC file, we do and wait for a DNS lookup on example.com.)
No longer depends on: fuzz-canvas2d-azure
Status: REOPENED → RESOLVED
Closed: 14 years ago → 12 years ago
Resolution: --- → WORKSFORME
Whiteboard: [orange]
You need to log in before you can comment on or make changes to this bug.