Closed
Bug 645227
Opened 14 years ago
Closed 14 years ago
Long delays are causing a global timeout with "application unexpectedly closed"
Categories
(Mozilla QA Graveyard :: Mozmill Tests, defect)
Mozilla QA Graveyard
Mozmill Tests
Tracking
(Not tracked)
RESOLVED
FIXED
People
(Reporter: lcamacho, Assigned: davehunt)
Details
(Whiteboard: [testday-110325][endurance-tests])
Attachments
(4 files, 1 obsolete file)
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:2.0) Gecko/20100101 Firefox/4.0
Build Identifier:
After two tries with endurance test the results is the same TEST-UNEXPECTED-FAIL | Disconnect Error: Application unexpectedly closed
Reproducible: Always
Reporter | ||
Comment 1•14 years ago
|
||
Includes the command and output from terminal
Reporter | ||
Comment 2•14 years ago
|
||
Includes the command and output from terminal
Reporter | ||
Updated•14 years ago
|
Whiteboard: testday-110325
Reporter | ||
Updated•14 years ago
|
Whiteboard: testday-110325 → [testday-110325]
Comment 3•14 years ago
|
||
I assume that is the same failure as what I have reported earlier this week on bug 643697. Adding dependency for now.
Status: UNCONFIRMED → NEW
Depends on: 643697
Ever confirmed: true
Whiteboard: [testday-110325] → [testday-110325][endurance-tests]
Reporter | ||
Comment 4•14 years ago
|
||
This was the third try for this I follow the instrucctions of Henrik (whimboo) I made a clone from https://github.com/mozautomation/mozmill change to hotfix-1.5.2 branch and applied the patch from bug https://bugzilla.mozilla.org/show_bug.cgi?id=643697 and the error persists as with the other logs this include the command and terminal output
Comment 5•14 years ago
|
||
Dave, can you please check that the global timeout which gets set on Mozmill is always longer than the delay an user can specify? As given by Clint, we run into a global timeout here.
OS: Linux → All
Hardware: x86_64 → All
Summary: Application unexpectedly closed → Long delays are causing a global timeout with "application unexpectedly closed"
Assignee | ||
Comment 6•14 years ago
|
||
Interesting. How would you suggest I do this? Multiply the delay by the iterations and add that to the global timeout? That won't take into account the time it takes for the test steps to run, which is an unknown amount of time. We cold multiply the global timeout by the number of iterations, but I suspect that would be overkill.
Comment 7•14 years ago
|
||
Each single test inside a function will cause data to get send. So we can say that we can live with the default timeout of 60s for one iteration but we should increase this value by the delay specified on the command line. That should be the safest solution.
Assignee | ||
Comment 8•14 years ago
|
||
This patch sets the timeout to 60 seconds, plus an additional delay that has been set by the user.
Assignee: nobody → dave.hunt
Attachment #523569 -
Flags: review?(anthony.s.hughes)
Assignee | ||
Comment 9•14 years ago
|
||
Added message to patch.
Attachment #523569 -
Attachment is obsolete: true
Attachment #523569 -
Flags: review?(anthony.s.hughes)
Attachment #523570 -
Flags: review?(anthony.s.hughes)
Attachment #523570 -
Flags: review?(anthony.s.hughes) → review+
Assignee | ||
Updated•14 years ago
|
Attachment #523570 -
Flags: review?(hskupin)
Updated•14 years ago
|
Attachment #523570 -
Flags: review?(hskupin) → review+
Comment 10•14 years ago
|
||
Landed as:
http://hg.mozilla.org/qa/mozmill-automation/rev/1cc8012aef74
Leonard, all the failures you have seen shouldn't be occurring anymore now.
Status: NEW → RESOLVED
Closed: 14 years ago
Resolution: --- → FIXED
Updated•6 years ago
|
Product: Mozilla QA → Mozilla QA Graveyard
You need to log in
before you can comment on or make changes to this bug.
Description
•