Closed Bug 487817 Opened 11 years ago Closed 11 years ago

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

Categories

(Core :: XUL, defect)

x86
Linux
defect
Not set
major

Tracking

()

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

People

(Reporter: dholbert, Assigned: smaug)

References

()

Details

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

Attachments

(1 file)

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
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?
Same as Bug 506596?
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: 11 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]
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: 11 years ago11 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.