Closed Bug 854038 Opened 12 years ago Closed 7 years ago

Delete crashes after job execution

Categories

(Testing :: General, defect)

defect
Not set
normal

Tracking

(Not tracked)

RESOLVED WONTFIX

People

(Reporter: gps, Unassigned)

Details

mconnor was running into issues where Firefox Health Report tests were timing out when running mochitests. We cranked up the logging of Firefox Health Report and pushed to try. https://tbpl.mozilla.org/php/getParsedLog.php?id=20992444&tree=Try&full=1 This log reveals that FHR is spending a lot of time collecting and recording crashes. Now, performance concerns of FHR aside, why are there dozens - possibly hundreds - of crashes on this machine? Why is there state from previous jobs lingering around to influence state of subsequent jobs? Crashes should at least be moved out of the way after job execution so they don't influence other jobs. If we don't care about them, they should be deleted completely. This bug is likely a subset of a larger bug: we don't delete the AppData directory (which is where crashes are stored).
(In reply to Gregory Szorc [:gps] from comment #0) > This bug is likely a subset of a larger bug: we don't delete the AppData > directory (which is where crashes are stored). This is a test harness issue.
Component: Release Engineering: Automation (General) → General
Product: mozilla.org → Testing
QA Contact: catlee
Version: other → unspecified
All of the automation.py-using test harnesses set MOZ_CRASHREPORTER_NO_REPORT, so crash reports never leave the temporary profile directory. (The crash reporter client is responsible for moving them to Crash Reports/pending.)
(In reply to Ted Mielczarek [:ted.mielczarek] from comment #2) > All of the automation.py-using test harnesses set > MOZ_CRASHREPORTER_NO_REPORT, so crash reports never leave the temporary > profile directory. (The crash reporter client is responsible for moving them > to Crash Reports/pending.) Well, FHR is finding files. So, they are either in the pending or submitted directories.
Mass closing bugs with no activity in 2+ years. If this bug is important to you, please re-open.
Status: NEW → RESOLVED
Closed: 7 years ago
Resolution: --- → WONTFIX
You need to log in before you can comment on or make changes to this bug.