Open
Bug 1228651
Opened 7 years ago
Updated 6 months ago
[mozcrash] Downloaded symbols should be cached
Categories
(Testing :: Mozbase, defect)
Testing
Mozbase
Tracking
(Not tracked)
NEW
People
(Reporter: whimboo, Unassigned)
Details
If there are multiple crashes happening during a complete test run mozcrash downloads the symbols again and again for each minidump file. Performance wise it would be good to cache symbols locally and re-use them if the signature is ok.
Comment 1•7 years ago
|
||
If all the crashes happen from a single browser run it should re-use the symbols. If a test run is running the browser multiple times then yes, they'll be re-downloaded every time. Do we have suites where that would actually happen, though? Usually we'd wind up failing and exiting the suite if something crashed. I suppose we could modify the API of `CrashInfo` to allow you to re-use it between runs. We'd probably want to refactor `log_crashes` / `check_for_crashes` into methods on `CrashInfo` so callers could do something like: ``` with CrashInfo(...) as crash_info: <run a test> crash_info.check_for_crashes(...) <run another test> crash_info.check_for_crashes(...) ```
Reporter | ||
Comment 2•7 years ago
|
||
(In reply to Ted Mielczarek [:ted.mielczarek] from comment #1) > If all the crashes happen from a single browser run it should re-use the > symbols. If a test run is running the browser multiple times then yes, > they'll be re-downloaded every time. Do we have suites where that would > actually happen, though? Usually we'd wind up failing and exiting the suite > if something crashed. Our firefox-ui-update tests have to do that because between the two updates we test (direct and fallback) we have to revert the binary to the pre build to be able to test the update again. In such a case we would even have two different versions of the binary under test, so caching in such a case would not be good. At least not without identifying the build correctly via eg. a hash or similar.
Comment 3•7 years ago
|
||
The symbols are already individually keyed by a UUID from the binaries, so it's not a problem to put symbols from two different builds in the same place.
Updated•6 months ago
|
Severity: normal → S3
You need to log in
before you can comment on or make changes to this bug.
Description
•