Confirmed users, Bureaucrats and Sysops emeriti
1,217
edits
Breakpad/Design: Difference between revisions
Terminology and logic fixes
ChrisHofmann (talk | contribs) |
(Terminology and logic fixes) |
||
| Line 5: | Line 5: | ||
* Airbag Client Customization - dcamp (Dave Camp) | * Airbag Client Customization - dcamp (Dave Camp) | ||
* Airbag Server | * Airbag Server | ||
** Crash/ | ** Crash/minidump Manager (Repeater + Collector) - morgamic (Mike Morgan) & TBD | ||
** Digester - luser (Ted Mielczarek) & TBD | ** Digester - luser (Ted Mielczarek) & TBD | ||
* Airbag Tools & Reporting - coop (Chris Cooper) & jay (Jay Patel) | * Airbag Tools & Reporting - coop (Chris Cooper) & jay (Jay Patel) | ||
| Line 17: | Line 17: | ||
* Platform integration for Windows, Mac OS X, Linux | * Platform integration for Windows, Mac OS X, Linux | ||
* UI parity with Mozilla products | * UI parity with Mozilla products | ||
** opt-in control for users to participate in sending data at all, and confirmation before sending any individual blackbox. also the ability to supply e-mail contact info, last visited site, and comments about activity leading up to the crash. | * crash minidumps will be stored on the user HD automatically. NOTE: need to delete on "Clear Private Data" | ||
* opt-in control for users to participate in sending data at all, and confirmation before sending any individual blackbox. also the ability to supply e-mail contact info, last visited site, and comments about activity leading up to the crash. | |||
* Collect and send data to Airbag Server | * Collect and send data to Airbag Server | ||
** Product info (product, version, platform, build id, airbag version) | ** Product info (product, version, platform, build id, airbag version) | ||
| Line 30: | Line 31: | ||
*** we could also consider improvements like auto filling crash url with info out of history, or send a recent history list under user control. | *** we could also consider improvements like auto filling crash url with info out of history, or send a recent history list under user control. | ||
** Stability statistics (total runtime, time since last crash, crash frequency, etc.) | ** Stability statistics (total runtime, time since last crash, crash frequency, etc.) | ||
** Minidumps automatically contain the list of DLLs in the process that crashed, which will give us plugin data | |||
* Store incident queue/history | * Store incident queue/history | ||
* Talkback also has the ability to receive config changes back from the server to control operations of the client. This is useful for such things as controls for shutting down the client for obsolete versions, slow down the transmission re-try rate or for another throttling mechanisms. | * Talkback also has the ability to receive config changes back from the server to control operations of the client. This is useful for such things as controls for shutting down the client for obsolete versions, slow down the transmission re-try rate or for another throttling mechanisms. | ||
== Airbag | == Airbag Minidump Collector == | ||
* Apache web server to manage incoming | * Apache web server to manage incoming minidumps via HTTPS | ||
* Pass | * Pass minidump data through the firewall | ||
* Monitor queue and | * Monitor queue and minidump status | ||
* Check client version and state and be able to serve config changes to Airbag Client (e.g. send message to disable client) | * Check client version and state and be able to serve config changes to Airbag Client (e.g. send message to disable client) | ||
* Prep | * Prep minidump for handoff to the processor | ||
* If we provide the configuration control feature the repeater also needs to push configuration info back down to the client for such things like "turn yourself off", "slow down your retry rate" and other control options. | * If we provide the configuration control feature the repeater also needs to push configuration info back down to the client for such things like "turn yourself off", "slow down your retry rate" and other control options. | ||
== Airbag Symbols Store == | == Airbag Symbols Store == | ||
* Infrastructure should allow build systems to push symbols to the Symbols Store | * Infrastructure should allow build systems to push symbols to the Symbols Store | ||
* Extension and plugin authors should also be able to upload PDB files for inclusion. | |||
* Store symbols for each build/release based on product information (similar to AUS URLs). Key parameters should include: | * Store symbols for each build/release based on product information (similar to AUS URLs). Key parameters should include: | ||
** Vendor/Project, Product, Product Version (?), Platform, OS Version (?), Build ID | ** Vendor/Project, Product, Product Version (?), Platform, OS Version (?), Build ID | ||
** Currently don't use Product or OS Versions with Talkback, but might want to consider doing it with Airbag. | ** Currently don't use Product or OS Versions with Talkback, but might want to consider doing it with Airbag. | ||
* Provide a Windows Symbol Server impl with the symbol data | |||
NOTE: the airbag processor does not need or use any product/version information to find symbols in the symbol store: all symbols are retrieved by unique image keys or checksums. However, in order to flush out old symbol data that is no longer relevant (especially from nightly builds), we will need to have a buildid/flushing strategy. | |||
== Airbag | == Airbag Processor == | ||
* Grab | * Grab minidumps from the collector | ||
* Process | * Process minidumps | ||
** Extract info from | ** Extract info from the minidump | ||
** Map stack trace to symbol info from Symbols Store to decipher function names, file paths and line no. | ** Map stack trace to symbol info from Symbols Store to decipher function names, file paths and line no. | ||
** Store crash information to Airbag Database | ** Store crash information to Airbag Database | ||
== Airbag Database == | == Airbag Database == | ||
* | * Use MySQL, like everything else | ||
* Define schema that works well with current query/reporting needs | * Define schema that works well with current query/reporting needs | ||
** [need to dig up all common queries - jay] | ** [need to dig up all common queries - jay] | ||
* The schema now accounts for the following kinds of information | * The schema now accounts for the following kinds of information | ||
** individual | ** individual minidump records | ||
** product/OS information | ** product/OS/buildid information | ||
** control information used to "register" an incoming | ** control information used to "register" an incoming minidump and monitor/track/control its progress though all the stages from being transfered from the client until it is fully collected and processed on the server and available for reporting and analysis. | ||
* using the same database and schema for the | * using the same database and schema for the minidump data and also for control over the processing of the minidumps has created problems in the past. when coruption is introduced, database performance problems crop up, or maintenance is required to manage the collection of minidumps, the processing of incoming minidumps is hindered and we start into a downward spiral of compounding problems. We should do some thinking to see if there are ways to improve on the existing design. | ||
== Analysis and Reporting System(s) == | == Analysis and Reporting System(s) == | ||
| Line 76: | Line 83: | ||
** the ability to find common themes behind crash reports by looking at things like common comments, common configuration characteristics such as OS version, graphics systems, process lists, time since last crash, most frequently visited sites, etc... | ** the ability to find common themes behind crash reports by looking at things like common comments, common configuration characteristics such as OS version, graphics systems, process lists, time since last crash, most frequently visited sites, etc... | ||
*** http://talkback-public.mozilla.org/reports/firefox/FF2001/url-analysis-all.html | *** http://talkback-public.mozilla.org/reports/firefox/FF2001/url-analysis-all.html | ||
* Properly segrate "public" data (stacks) and "private" data (parameters, which may contain sensitive information) | |||