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

RESOLVED FIXED in mozilla1.9.2b1

Status

()

--
major
RESOLVED FIXED
10 years ago
6 years ago

People

(Reporter: dholbert, Assigned: smaug)

Tracking

({intermittent-failure, verified1.9.1})

Trunk
mozilla1.9.2b1
x86
Linux
intermittent-failure, verified1.9.1
Points:
---
Dependency tree / graph
Bug Flags:
blocking1.9.2 -
wanted1.9.2 -
in-testsuite +

Firefox Tracking Flags

(status1.9.1 .3-fixed)

Details

(Whiteboard: [(fully) fixed by bug 513707] [test which aborts the suite] , URL)

Attachments

(1 attachment)

(Reporter)

Description

10 years ago
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.
(Reporter)

Updated

10 years ago
Summary: Mochitest timeout during content/tests/widgets/test_popup_attribute.xul → Sporadic mochitest timeout during content/tests/widgets/test_popup_attribute.xul
Whiteboard: [orange]
(Reporter)

Updated

10 years ago
Component: Content → XUL
QA Contact: content → xptoolkit.widgets
(Reporter)

Updated

10 years ago
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=Firefox/1249479426.1249485848.17288.gz
Linux mozilla-central unit test on 2009/08/05 06:37:06
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

Comment 16

10 years ago
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.
Created attachment 393429 [details] [diff] [review]
patch
[Checkin: Comment 25 & 27]

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.

Comment 20

10 years ago
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 23

10 years ago
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
Last Resolved: 10 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

Comment 29

9 years ago
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]
Linux mozilla-central test mochitests on 2009/09/06 22:36:12  
http://tinderbox.mozilla.org/showlog.cgi?log=Firefox-Unittest/1252301772.1252303956.22975.gz#err0
So why has this started to happen again?
Did Bug 513707 regress this?
...in which case a new bug should have been filed.

Comment 37

9 years ago
Should be fixed by 513707.

Updated

9 years ago
Status: REOPENED → RESOLVED
Last Resolved: 10 years ago9 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]
Keywords: intermittent-failure
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.