Difference between revisions of "Viewer Crash Reporting"
Jump to navigation
Jump to search
Ramzi Linden (talk | contribs) |
Ramzi Linden (talk | contribs) |
||
| Line 9: | Line 9: | ||
Studio Shiny has committed to making the Second Life viewer more stable. This involves finding and fixing viewer crashes. We have found that the existing crash reporter doesn't help us as much as it should. It doesn't always give us the data we need to investigate crash patterns, doesn't scale to SL's current size, doesn't always report a crash, in fact, sometimes the crash reporter itself crashes. | Studio Shiny has committed to making the Second Life viewer more stable. This involves finding and fixing viewer crashes. We have found that the existing crash reporter doesn't help us as much as it should. It doesn't always give us the data we need to investigate crash patterns, doesn't scale to SL's current size, doesn't always report a crash, in fact, sometimes the crash reporter itself crashes. | ||
= Phase 1 = | = Tasks = | ||
== Phase 1 == | |||
* Create central library of crash reporter functionality | * Create central library of crash reporter functionality | ||
* Get near 100% of all crashes reported with the call stack included | * Get near 100% of all crashes reported with the call stack included, which pinpoints the function or method in which the crash occurred. | ||
= Phase 2 = | == Phase 2 == | ||
* Refinements to the crash reporter functionality | * Refinements to the crash reporter functionality | ||
** properly capture crashes before login or viewer initialization | ** properly capture crashes before login or viewer initialization | ||
== Viewer Crash Hunters == | |||
* A team of engineers will utilize the new Viewer Crash Reporter to identify the highest reported crashes and investigate the call stacks to pinpoint bugs. | |||
* The project is gated on the adoption of | |||
** the 1.19.0.5 viewer which utilizes the new crash reporter. | |||
** the 1.19.1 viewer which also provides stack info on "deadlocks" (in which a crash occurs, but in a different thread.) | |||
** implementation TBD of a watchdog process to detect deadlock situation and force a "normal" crash that reports the crashing thread | |||
= See Also = | = See Also = | ||
* [[Viewer Roadmap]] | * [[Viewer Roadmap]] | ||
Revision as of 17:26, 31 March 2008
Objectives
- Report all crashes properly (opt-out available)
- Make crash report processing automatic and immediate
- Make crash report data useful
Motivation
Studio Shiny has committed to making the Second Life viewer more stable. This involves finding and fixing viewer crashes. We have found that the existing crash reporter doesn't help us as much as it should. It doesn't always give us the data we need to investigate crash patterns, doesn't scale to SL's current size, doesn't always report a crash, in fact, sometimes the crash reporter itself crashes.
Tasks
Phase 1
- Create central library of crash reporter functionality
- Get near 100% of all crashes reported with the call stack included, which pinpoints the function or method in which the crash occurred.
Phase 2
- Refinements to the crash reporter functionality
- properly capture crashes before login or viewer initialization
Viewer Crash Hunters
- A team of engineers will utilize the new Viewer Crash Reporter to identify the highest reported crashes and investigate the call stacks to pinpoint bugs.
- The project is gated on the adoption of
- the 1.19.0.5 viewer which utilizes the new crash reporter.
- the 1.19.1 viewer which also provides stack info on "deadlocks" (in which a crash occurs, but in a different thread.)
- implementation TBD of a watchdog process to detect deadlock situation and force a "normal" crash that reports the crashing thread