Closed
Bug 419492
Opened 18 years ago
Closed 18 years ago
talos needs to ensure that browser is closed at end of testing.
Categories
(Release Engineering :: General, defect, P3)
Release Engineering
General
Tracking
(Not tracked)
RESOLVED
FIXED
People
(Reporter: anodelman, Assigned: anodelman)
Details
Attachments
(1 file)
|
21.57 KB,
patch
|
rcampbell
:
review+
|
Details | Diff | Splinter Review |
This would protect against bug 415298.
| Assignee | ||
Comment 1•18 years ago
|
||
Also, buildbot should ensure that no browsers are running before starting a talos run.
| Assignee | ||
Updated•18 years ago
|
Assignee: anodelman → nobody
Component: Testing → Release Engineering
Priority: -- → P3
Product: Core → mozilla.org
QA Contact: testing → release
Version: unspecified → other
| Assignee | ||
Updated•18 years ago
|
Assignee: nobody → anodelman
| Assignee | ||
Comment 2•18 years ago
|
||
Most of this is fixed through the 'better process killing on timeout' patch in bug 416911.
There are still a couple of edge cases where this could occur:
- the browser doesn't make it through initial metric calculations and process cleanup calls are never made
- process cleanup tries to kill a process owned by root (happens with dwwin.exe on windows and crashdump on mac) and only makes it part way through clean up.
| Assignee | ||
Comment 3•18 years ago
|
||
This is pretty much a re-write of how talos monitors processes for existence and then goes about killing them. I've added support for handling errors through exceptions (instead of watching for result variables to be true/false) and more and better profile clean up after a crash.
The only thing that I don't like here is the use of time.sleep to put in delays before checking for existence of processes. This is only there for winxp/vista where processes take longer to close themselves down.
This patch is currently running on the staging talos boxes, so all the machines reporting to MozillaTest as talos stage are using it - doesn't seem to interfere with number collection or basic operation.
Attachment #315002 -
Flags: review?(rcampbell)
Updated•18 years ago
|
Attachment #315002 -
Flags: review?(rcampbell) → review+
| Assignee | ||
Comment 4•18 years ago
|
||
Checking in ffprocess_linux.py;
/cvsroot/mozilla/testing/performance/talos/ffprocess_linux.py,v <-- ffprocess_linux.py
new revision: 1.8; previous revision: 1.7
done
Checking in ffprocess_mac.py;
/cvsroot/mozilla/testing/performance/talos/ffprocess_mac.py,v <-- ffprocess_mac.py
new revision: 1.9; previous revision: 1.8
done
Checking in ffprocess_win32.py;
/cvsroot/mozilla/testing/performance/talos/ffprocess_win32.py,v <-- ffprocess_win32.py
new revision: 1.6; previous revision: 1.5
done
Checking in ffsetup.py;
/cvsroot/mozilla/testing/performance/talos/ffsetup.py,v <-- ffsetup.py
new revision: 1.5; previous revision: 1.4
done
Checking in run_tests.py;
/cvsroot/mozilla/testing/performance/talos/run_tests.py,v <-- run_tests.py
new revision: 1.27; previous revision: 1.26
done
Checking in ttest.py;
/cvsroot/mozilla/testing/performance/talos/ttest.py,v <-- ttest.py
new revision: 1.14; previous revision: 1.13
done
Checking in utils.py;
/cvsroot/mozilla/testing/performance/talos/utils.py,v <-- utils.py
new revision: 1.5; previous revision: 1.4
done
| Assignee | ||
Comment 5•18 years ago
|
||
This has cycled a few times and looks to not be interfering with basic operation. I've split off the crash reporter issues into bug 429040.
Status: NEW → RESOLVED
Closed: 18 years ago
Resolution: --- → FIXED
Updated•13 years ago
|
Product: mozilla.org → Release Engineering
You need to log in
before you can comment on or make changes to this bug.
Description
•