Closed Bug 487817 Opened 16 years ago Closed 15 years ago

[Linux] mochitest-plain: test_popup_attribute.xul intermittently times out

Categories

(Core :: XUL, defect)

Product:
Core
Component:
XUL
Platform:
x86
Linux
Type:
defect
Priority:
Not set
Severity:
major

Tracking

()

Status:
RESOLVED FIXED
Milestone:
mozilla1.9.2b1
Tracking Flags:
Tracking Status
status1.9.1 --- .3-fixed

People

(Reporter: dholbert, Assigned: smaug)

References

(
URL
)

Details

(Keywords: intermittent-failure, verified1.9.1, Whiteboard: [(fully) fixed by bug 513707] [test which aborts the suite] )

Attachments

(1 file)

patch [Checkin: Comment 25 & 27]
3.26 KB, patch
enndeakin
: review+
Details | Diff | Splinter Review
The linux 1.9.1 unittest box just timed out (300 sec) during test_popup_attribute.xul. Here's the relevant snippet from the log: *** 78015 INFO Running /tests/toolkit/content/tests/widgets/test_popup_attribute.xul... command timed out: 300 seconds without output, killing pid 18305 process killed by signal 9 program finished with exit code -1 elapsedTime=2909.866071 TinderboxPrint: mochitest-plain<br/><em class="testfail">T-FAIL</em> buildbot.slave.commands.TimeoutError: command timed out: 300 seconds without output, killing pid 18305 Linux mozilla-1.9.1 unit test on 2009/04/10 08:02:06 http://tinderbox.mozilla.org/showlog.cgi?tree=Firefox3.5&errorparser=unittest&logfile=1239375726.1239384209.8645.gz&buildtime=1239375726&buildname=Linux%20mozilla-1.9.1%20unit%20test&fulltext=1 Link to test: http://mxr.mozilla.org/mozilla-central/source/toolkit/content/tests/widgets/test_popup_attribute.xul This failure wasn't due to a checkin, because the previous cycle was built from the same changeset and was green.
Summary: Mochitest timeout during content/tests/widgets/test_popup_attribute.xul → Sporadic mochitest timeout during content/tests/widgets/test_popup_attribute.xul
Whiteboard: [orange]
Component: Content → XUL
QA Contact: content → xptoolkit.widgets
Summary: Sporadic mochitest timeout during content/tests/widgets/test_popup_attribute.xul → Sporadic mochitest-process timeout (300 seconds without output) during test_popup_attribute.xul
http://tinderbox.mozilla.org/showlog.cgi?log=Firefox/1244747510.1244754764.5940.gz Linux mozilla-central unit test on 2009/06/11 12:11:50
Blocks: 388995
URL: http://tinderbox.mozilla.org/showlog.... → http://mxr.mozilla.org/mozilla-centra...
Summary: Sporadic mochitest-process timeout (300 seconds without output) during test_popup_attribute.xul → [Linux] mochitest-plain: test_popup_attribute.xul intermittently times out
http://tinderbox.mozilla.org/showlog.cgi?log=MozillaTry/1248227645.1248235955.7515.gz Linux try hg unit test on 2009/07/21 18:54:05
Flags: wanted1.9.2?
Flags: wanted1.9.2?
Flags: wanted1.9.2-
Flags: blocking1.9.2-
http://tinderbox.mozilla.org/showlog.cgi?log=MozillaTry/1249749439.1249756254.28921.gz Linux try hg unit test on 2009/08/08 09:37:19 Please, disable or work around tests which abort the suite.
I take this for now, since IIRC I can reproduce this all the time on 64bit linux (debug build).
Assignee: nobody → Olli.Pettay
Olli, can you create a debugging log of focus output? It would be nice to find out what's causing the problems with linux tests.
Sure, I'll try to create some log. The testcase is anyway wrong. It assumes that focus event may not happen before var gDone = false; is executed. There are several script elements before that code, so event loops does run.
A bit ugly, but should work. Similar fix for window_menubar.xul which fails occasionally here.
Attachment #393429 - Flags: review?(enndeakin)
I uploaded the patch to tryserver.
So maybe we should wait for both the load and focus events for focus/key tests if this is the cause of the general problem on Linux. I think having a SimpleTest.waitForLoadAndFocus(callback) type function which can be called from within a script would be a good idea. Then we could just use this instead for any test that needs it.
If this will fix a whole class of tests, then I wholeheartedly support putting it in the test framework.
Enn, would it make sense to first try this patch perhaps for few days to make sure it really fixes this problem and then write more generic approach and patch whatever tests need patching.
Comment on attachment 393429 [details] [diff] [review] patch [Checkin: Comment 25 & 27] >+ onload="window.gLoaded = true; setTimeout('maybeRunTests()', 0);" >+ onfocus="window.gFocused = true; setTimeout('maybeRunTests()', 0);" setTimeout(maybeRunTests, 0) should be ok in all four cases, no? Is the timeout actually needed?
Attachment #393429 - Flags: review?(enndeakin) → review+
(In reply to comment #23) > setTimeout(maybeRunTests, 0) should be ok in all four cases, no? mayRunTests may not be defined yet, so that is why I use maybeRunTests > Is the timeout actually needed? Yes, IIRC, it is.
http://hg.mozilla.org/mozilla-central/rev/99581edb2000 Marking fixed, please reopen if you still see this.
Status: NEW → RESOLVED
Closed: 15 years ago
Resolution: --- → FIXED
Flags: in-testsuite+
Target Milestone: --- → mozilla1.9.2b1
http://tinderbox.mozilla.org/showlog.cgi?log=SeaMonkey2.0/1250587317.1250594413.12264.gz Linux comm-1.9.1 unit test on 2009/08/18 02:21:57 { 78899 INFO Running /tests/toolkit/content/tests/widgets/test_popup_attribute.xul... Document http://localhost:8888/tests/toolkit/content/tests/widgets/window_popup_attribute.xul loaded successfully command timed out: 300 seconds without output, killing pid 7011 }
status1.9.1: --- → ?
Keywords: checkin-needed
Whiteboard: [orange] → [c-n: m-1.9.1] [orange]
Comment on attachment 393429 [details] [diff] [review] patch [Checkin: Comment 25 & 27] http://hg.mozilla.org/releases/mozilla-1.9.1/rev/456dcc91a7ee
Attachment #393429 - Attachment description: patch → patch [Checkin: Comment 25 & 27]
status1.9.1: ? → .3-fixed
Keywords: checkin-needed
Whiteboard: [c-n: m-1.9.1] [orange] → [orange]
Now with 3 days without orangeness it looks like we can call this bug as verified fixed.
Status: RESOLVED → VERIFIED
Keywords: verified1.9.1
I filed bug 513707 on adding a generic method.
http://tinderbox.mozilla.org/showlog.cgi?log=Firefox/1252105604.1252114132.5807.gz Linux mozilla-central unit test on 2009/09/04 16:06:44
Severity: normal → major
Status: VERIFIED → REOPENED
Resolution: FIXED → ---
Whiteboard: [orange] → [test which aborts the suite] [orange]
So why has this started to happen again? Did Bug 513707 regress this?
...in which case a new bug should have been filed.
Should be fixed by 513707.
Status: REOPENED → RESOLVED
Closed: 15 years ago → 15 years ago
Resolution: --- → FIXED
No longer blocks: 451482
Depends on: 513707
Whiteboard: [test which aborts the suite] [orange] → [(fully) fixed by 513707] [test which aborts the suite] [orange]
Whiteboard: [(fully) fixed by 513707] [test which aborts the suite] [orange] → [(fully) fixed by bug 513707] [test which aborts the suite] [orange]
Whiteboard: [(fully) fixed by bug 513707] [test which aborts the suite] [orange] → [(fully) fixed by bug 513707] [test which aborts the suite]
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: