Closed Bug 592402 Opened 14 years ago Closed 12 years ago

Intermittent test_offsets.xul | Test timed out

Categories

(Core :: DOM: Core & HTML, defect)

Product:
Core
Component:
DOM: Core & HTML
Platform:
All
Linux
Type:
defect
Priority:
Not set
Severity:
major

Tracking

()

Status:
RESOLVED WORKSFORME
Tracking Flags:
Tracking Status
blocking2.0 --- -

People

(Reporter: philor, Unassigned)

References

(
URL
)

Details

(Keywords: intermittent-failure, Whiteboard: [qaw: see comments 52, 145, 147 and 239+240] )

http://tinderbox.mozilla.org/showlog.cgi?log=Firefox/1283281669.1283282620.19640.gz Rev3 Fedora 12 mozilla-central opt test mochitests-3/5 on 2010/08/31 12:07:49 s: talos-r3-fed-025 5608 INFO TEST-PASS | /tests/dom/tests/mochitest/general/test_offsets.xul | svgrect scrollTop after nonscroll - 0 should equal 0 5609 ERROR TEST-UNEXPECTED-FAIL | /tests/dom/tests/mochitest/general/test_offsets.xul | Test timed out. There's a screenshot in the log, but it doesn't seem to show any smoking guns.
It seems like this happened first on http://hg.mozilla.org/mozilla-central/rev/fdf35ea63a85. The only relevant changeset pushed a short while before that is dbaron's bug 585715...
It's not clear to me why my changes would be relevant, especially for the test timing out. That seems more likely to be related to the popup stuff it does, perhaps? In any case, I ran the test under valgrind and didn't see any warnings (though I probably should have tried with the pres arena turned off as well).
Comment 40 isn't this, it was a backed-out patch.
Bug 615546 supposedly made this bug happen more often...
Blocks: 615546
Summary: Intermittent test_offsets.xul | Test timed out → mochitests-3: intermittent "test_offsets.xul | Test timed out"
Your self-invented scheme for summaries doesn't actually help anything.
Summary: mochitests-3: intermittent "test_offsets.xul | Test timed out" → Intermittent test_offsets.xul | Test timed out
(In reply to comment #47) > Bug 615546 supposedly made this bug happen more often... Confirmed. Normal -> Major: as this prevents landing that harness fix. Unless we disable this test until it is fixed? (In reply to comment #49) > Your self-invented scheme for summaries doesn't actually help anything. At least, it helps (me) to easily know which test suite is affected... What harm does that do?
URL: http://mxr.mozilla.org/mozilla-centra...
Severity: normal → major
Adding random visual noise to summaries makes it harder to spot the only two things that matter, the test name and the failure message, when multiple bugs are suggested in tbpl. And "mochitest-n" is nothing but noise - which chunk of mochitest it's in isn't decided at birth, it's just a function of how many tests there are in what directories. That's like saying "my car was stolen, the guy drove away in the right lane, so look for it in the right lane."
Ftr, This test was added in http://hg.mozilla.org/mozilla-central/rev/2e8dfe209f09 "Add clientXXX and scrollXXX properties to XUL elements, also add width/height properties to ClientRect" Passing log examples: Linux and Windows: { svgrect scrollTop after nonscroll - 0 should equal 0 outerpopup scrollLeft - 0 should equal 0 } MacOSX: (which has extra checks) { svgrect scrollTop after nonscroll - 0 should equal 0 popup before open scrollLeft - 0 should equal 0 popup before open scrollTop - 0 should equal 0 popup before open scrollWidth - 0 should equal 0 popup before open scrollHeight - 0 should equal 0 popup before open clientLeft - 0 should equal 0 popup before open clientTop - 0 should equal 0 popup before open clientWidth - 0 should equal 0 popup before open clientHeight - 0 should equal 0 outerpopup scrollLeft - 0 should equal 0 } And the test usually passes in 1-2 seconds. Timeouts are always _after_ passing "svgrect scrollTop after nonscroll". *** I don't see anything obviously wrong. Then, I'll Try 1-2 guess(es) I have...
Depends on: 565307
OS: Linux → All
Hardware: x86 → All
No longer blocks: 615546
(In reply to comment #52) > I don't see anything obviously wrong. > Then, I'll Try 1-2 guess(es) I have... None of my guesses worked. Fwiw, { - onpopupshown="testElements('outermenu', doneTests)"> + onpopupshown="setTimeout(testElements, 0, 'outermenu', doneTests);"> } made no difference. *** From the debug logs, it seems the "hang" happens during/after |$("outermenu").open = true;|: some DOCSHELL+DOMWINDOW releases happen, then/but the second part of the test doesn't start. *** (In reply to comment #120) > http://hg.mozilla.org/mozilla-central/rev/36d993e97158 It seems this s/setTimeout/waitForFocus/ when the test starts didn't help. Could the test be losing focus while it runs? Can anyone reproduce this failure locally? (To confirm what is (not) happening.)
OS: All → Linux
(In reply to comment #51) > Adding random visual noise to summaries makes it harder to spot the only two > things that matter, the test name and the failure message, when multiple bugs > are suggested in tbpl. Hum, TBPL is not the only tool... > And "mochitest-n" is nothing but noise - which chunk of > mochitest it's in isn't decided at birth, it's just a function of how many > tests there are in what directories. That's like saying "my car was stolen, the > guy drove away in the right lane, so look for it in the right lane." It can be useful to have this data in (some) BugZilla search results, for example...
(In reply to comment #50) > Unless we disable this test until it is fixed? At least, you could add some "dump()" in doneTests() and the 2 onpopupshown() to narrow down were the test hangs exactly...
"blocking2.0=?": Not strictly blocking the release, but this test (random failure) blocks keeping bug 615546 in the tree, which keeps many "improperly written" tests as not behaving "correctly" as they should (and needing workarounds). Hopefully, the fact that bug 615546 harness fix causes this random failure should give a clue about what is "fragile" in this test...
blocking2.0: --- → ?
Keywords: qawanted
Whiteboard: [orange] → [qaw: see comments 52, 145, 147 and 239] [orange]
Also, given how frequent bug 615546 makes this bug, it should be "easy" to record a failing run and analyze it, if need be.
Whiteboard: [qaw: see comments 52, 145, 147 and 239] [orange] → [qaw: see comments 52, 145, 147 and 239+240] [orange]
I'd approve a safe fix for this in a heartbeat, but I'm not going to hold the release.
blocking2.0: ? → -
Mass marking whiteboard:[orange] bugs WFM (to clean up TBPL bug suggestions) that: * Haven't changed in > 6months * Whose whiteboard contains none of the strings: {disabled,marked,random,fuzzy,todo,fails,failing,annotated,leave open,time-bomb} * Passed a (quick) manual inspection of bug summary/whiteboard to ensure they weren't a false positive. I've also gone through and searched for cases where the whiteboard wasn't labelled correctly after test disabling, by using attachment description & basic comment searches. However if the test for which this bug was about has in fact been disabled/annotated/..., please accept my apologies & reopen/mark the whiteboard appropriately so this doesn't get re-closed in the future (and please ping me via IRC or email so I can try to tweak the saved searches to avoid more edge cases). Sorry for the spam! Filter on: #FFA500
Status: NEW → RESOLVED
Closed: 12 years ago
Resolution: --- → WORKSFORME
Whiteboard: [qaw: see comments 52, 145, 147 and 239+240] [orange] → [qaw: see comments 52, 145, 147 and 239+240]
Issue is resolved - clearing old keywords - qa-wanted clean-up
Keywords: qawanted
Component: DOM → DOM: Core & HTML
You need to log in before you can comment on or make changes to this bug.