Closed Bug 948895 Opened 12 years ago Closed 11 years ago

Intermittent raise ScriptTimeoutException(message=message, status=status, stacktrace=stacktrace) errors.ScriptTimeoutException: timed out

Categories

(Remote Protocol :: Marionette, defect)

x86
Linux
defect
Not set
normal

Tracking

(Not tracked)

RESOLVED INCOMPLETE

People

(Reporter: cbook, Unassigned)

References

()

Details

Attachments

(1 file)

b2g_emulator_vm b2g-inbound opt test marionette-webapi on 2013-12-10 23:04:23 PST for push 67bcb37ba888 slave: tst-linux64-ec2-111 https://tbpl.mozilla.org/php/getParsedLog.php?id=31790766&tree=B2g-Inbound raise ScriptTimeoutException(message=message, status=status, stacktrace=stacktrace) errors.ScriptTimeoutException: timed out
The instances in comment 40 to comment 51 with test_mobile_data_connection.js is the failure message were actually bustage, fixed by backout: https://hg.mozilla.org/mozilla-central/rev/654854b387dd Wes/Tomcat, please can we be extra careful to double check failures that seem to have suddenly spiked, to check that they are not now perma-orange :-)
We're hitting this really frequently lately. Can we get someone to look at it please? 11:12:55 INFO - starting httpd 11:12:55 INFO - running webserver on http://10.134.57.180:44700/ 11:15:50 INFO - waiting for system-message-listener-ready... 11:16:20 INFO - done 11:16:38 INFO - waiting for homescreen... 11:17:40 INFO - Traceback (most recent call last): 11:17:40 INFO - File "/builds/slave/test/build/tests/marionette/marionette/runtests.py", line 33, in <module> 11:17:40 INFO - cli() 11:17:40 INFO - File "/builds/slave/test/build/tests/marionette/marionette/runtests.py", line 28, in cli 11:17:40 INFO - runner = startTestRunner(runner_class, options, tests) 11:17:40 INFO - File "/builds/slave/test/build/tests/marionette/marionette/runtests.py", line 19, in startTestRunner 11:17:40 INFO - runner.run_tests(tests) 11:17:40 INFO - File "/builds/slave/test/build/tests/marionette/marionette/runner/base.py", line 725, in run_tests 11:17:40 INFO - self.run_test(test) 11:17:40 INFO - File "/builds/slave/test/build/tests/marionette/marionette/runner/base.py", line 770, in run_test 11:17:40 INFO - self.marionette.emulator.wait_for_homescreen(self.marionette) 11:17:40 INFO - File "/builds/slave/test/build/tests/marionette/marionette/emulator.py", line 363, in wait_for_homescreen 11:17:40 INFO - });""", script_timeout=60000) 11:17:40 INFO - File "/builds/slave/test/build/tests/marionette/marionette/marionette.py", line 1149, in execute_async_script 11:17:40 INFO - filename=os.path.basename(frame[0])) 11:17:40 INFO - File "/builds/slave/test/build/tests/marionette/marionette/marionette.py", line 605, in _send_message 11:17:40 INFO - self._handle_error(response) 11:17:40 INFO - File "/builds/slave/test/build/tests/marionette/marionette/marionette.py", line 654, in _handle_error 11:17:40 ERROR - raise ScriptTimeoutException(message=message, status=status, stacktrace=stacktrace) 11:17:40 ERROR - errors.ScriptTimeoutException: ScriptTimeoutException: timed out 11:17:42 ERROR - Return code: 1
Flags: needinfo?(overholt)
This is the script that's timing out. We might not be getting the mozbrowserloadend event, or else it's taking longer than it used to. (We could try increasing the timeout.)
(In reply to Jonathan Griffin (:jgriffin) from comment #109) > This is the script that's timing out. We might not be getting the > mozbrowserloadend event, or else it's taking longer than it used to. (We > could try increasing the timeout.) Oops, the link to the script is here: http://mxr.mozilla.org/mozilla-central/source/testing/marionette/client/marionette/emulator.py#358
Let's see if increasing the timeout helps this problem, and add some logging in case it doesn't.
Attachment #8367694 - Flags: review?(ahalberstadt)
Assignee: nobody → jgriffin
Comment on attachment 8367694 [details] [diff] [review] Increase wait-for-homescreen timeout, Review of attachment 8367694 [details] [diff] [review]: ----------------------------------------------------------------- Looks good. I had to increase this very timeout to get Mnw working on debug emulators, so I wouldn't be surprised if a minute is too short :(
Attachment #8367694 - Flags: review?(ahalberstadt) → review+
Whiteboard: [leave open]
Target Milestone: --- → mozilla29
I'm pretty optimistic my patch fixed this, as there haven't been any occurrences on inbound since it landed.
Assignee: jgriffin → nobody
(In reply to Jonathan Griffin (:jgriffin) from comment #168) > I'm pretty optimistic my patch fixed this, as there haven't been any > occurrences on inbound since it landed. There are some comments with inbound jobs mentioned after comment #168 ... does that mean your patch didn't fix this?
Flags: needinfo?(overholt)
(In reply to Andrew Overholt [:overholt] from comment #195) > (In reply to Jonathan Griffin (:jgriffin) from comment #168) > > I'm pretty optimistic my patch fixed this, as there haven't been any > > occurrences on inbound since it landed. > > There are some comments with inbound jobs mentioned after comment #168 ... > does that mean your patch didn't fix this? No, it means there are several causes of this problem, and my patch fixed the most general cause (a failure during startup), but didn't address the specific problems that can be related to individual tests, which still occur. Ideally, these more specific failures would be filed as distinct bugs, but I think it can be hard for sheriffs to distinguish them.
Filed bug 967318 to help us report the errors better.
(In reply to Carsten Book [:Tomcat] from comment #175) > https://hg.mozilla.org/mozilla-central/rev/70d91614a191 FYI, I've pushed this patch to b2g28 (v1.3) for Bug 986063
Depends on: 989728
This intermittent failure is #8 on OrangeFactor, and as such worthy of escalation due to https://wiki.mozilla.org/Sheriffing/Test_Disabling_Policy Needinfo'ing an appropriate person for estimation of next steps & timeframe. The policy requires that I state that after two working days a needinfo on the module owner will be added (if they aren't already), and failing that - the test disabled 2 working days after that. But that's an absolutely last resort :-)
Flags: needinfo?(jgriffin)
(In reply to Ed Morley [:edmorley UTC+0] from comment #503) > This intermittent failure is #8 on OrangeFactor, and as such worthy of > escalation due to https://wiki.mozilla.org/Sheriffing/Test_Disabling_Policy > > Needinfo'ing an appropriate person for estimation of next steps & timeframe. > The policy requires that I state that after two working days a needinfo on > the module owner will be added (if they aren't already), and failing that - > the test disabled 2 working days after that. But that's an absolutely last > resort :-) Note that I split out the test_audiomanager_phonestate.js into bug 1004152 yesterday, though I still see plenty of stars for that particular failure here since. Same for other tests that have bugs on file...
(In reply to Ryan VanderMeulen [:RyanVM UTC-4] from comment #505) > Note that I split out the test_audiomanager_phonestate.js into bug 1004152 > yesterday, though I still see plenty of stars for that particular failure > here since. Same for other tests that have bugs on file... Yeah true - we should get bug 967318 fixed asap & then this will stop being a dumping ground :-)
Depends on: 967318
Depends on: 1006511
This bug as-filed isn't actionable. Now that bug 967318 is fixed, we should file bugs for the individual test failures rather than dumping them all in here.
Status: NEW → RESOLVED
Closed: 11 years ago
Flags: needinfo?(jgriffin)
Resolution: --- → INCOMPLETE
Whiteboard: [leave open]
Target Milestone: mozilla29 → ---
Product: Testing → Remote Protocol
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Created:
Updated:
Size: