Account confirmers, Anti-spam team, canmove, Confirmed users, Bureaucrats and Sysops emeriti
4,083
edits
User:KaiRo/Filing Crash Bugs: Difference between revisions
Jump to navigation
Jump to search
no edit summary
No edit summary |
No edit summary |
||
| Line 4: | Line 4: | ||
* For one thing, use the "Bugzilla - Report this bug in ..." links in a representative crash report on crash-stats (under the table of crash information on the "Details" tab). If you are looking at a list of crashes, e.g. a Signature Summary, you ideally look through a few reports to select a representative that has a good stack and as few extensions installed as possible. | * For one thing, use the "Bugzilla - Report this bug in ..." links in a representative crash report on crash-stats (under the table of crash information on the "Details" tab). If you are looking at a list of crashes, e.g. a Signature Summary, you ideally look through a few reports to select a representative that has a good stack and as few extensions installed as possible. | ||
** The best way to detect if a stack is "good" is to look at a few ones. When you have some that have random hexadecimal addresses in them or that end after just a few lines (frames), those are somewhat "bad". If you have multiple crash reports available, try to find one where the stack does not contain such random address and is going down for a more than 10-15 frames, if possible. That helps developers find the whole trace of functions that have been called to get to the place that finally crashed. | |||
* Select a fitting product and component for what you think is the cause of the crash. | * Select a fitting product and component for what you think is the cause of the crash. | ||
** If you don't have good knowledge of our code and Bugzilla hierarchies, it can be helpful to look into bugs connected with recent changes to the files linked in the significant top frames of the stack. This takes a number of clicks, but clicking at those links at the right-side column of the stack and then clicking "revisions" at the top of the resulting page (on hg.mozilla.org) is quite helpful and links to bugs that changed this code recently. Using the product/components mostly mentioned in those bugs for recent entries is usually a good start. | ** If you don't have good knowledge of our code and Bugzilla hierarchies, it can be helpful to look into bugs connected with recent changes to the files linked in the significant top frames of the stack. This takes a number of clicks, but clicking at those links at the right-side column of the stack and then clicking "revisions" at the top of the resulting page (on hg.mozilla.org) is quite helpful and links to bugs that changed this code recently. Using the product/components mostly mentioned in those bugs for recent entries is usually a good start. | ||
| Line 11: | Line 12: | ||
* Include a link to more reports with the same signature, e.g. by copying the URL from the "More Reports" link next to the signature in the Details table of the crash report. | * Include a link to more reports with the same signature, e.g. by copying the URL from the "More Reports" link next to the signature in the Details table of the crash report. | ||
* It helps including the top few stack frames in the bug - you can potentially cut the list off at a point where it seems to go generic and unrelated to the actual issue, but if you are not sure, include it all. | * It helps including the top few stack frames in the bug - you can potentially cut the list off at a point where it seems to go generic and unrelated to the actual issue, but if you are not sure, include it all. | ||
** This is another step that involves some guessing. A good thumb rule is to not go much further than 10 frames, and often you have something generic like nsThread::ProcessNextEvent in there, which usually is a good point to cut off and add a "[...]" at the end. See for example what was done in {{bug|1074196}}. | ** This is another step that involves some guessing. A good thumb rule is to not go much further than 10-15 frames, and often you have something generic like nsThread::ProcessNextEvent in there, which usually is a good point to cut off and add a "[...]" at the end. See for example what was done in {{bug|1074196}}. | ||
** "Generic" there is meant in what the code is doing. If it's part of an event loop, for example (stuff like "ProcessNextEvent" or so point to that), this is very generic. Also, functions that actually just handle the error but didn't produce it themselves, like "malloc_abort" are also pretty generic. | |||
* If it's a crash you encountered, it helps to tell developers in the bug what you remember doing when the crash occurred, if possible. | * If it's a crash you encountered, it helps to tell developers in the bug what you remember doing when the crash occurred, if possible. | ||
* If you file based on data, please include data about when it started to appear, how high it is in overall volume (and/or topcrash reports), and any information that is outside the average sample (i.e. only happening on specific OSes, specific Firefox versions, specific Graphics cards, or significant correlations with any modules or add-ons). Also, if comments tell anything about commonalities of actions and/or possible steps to reproduce, please include that. | * If you file based on data, please include data about when it started to appear, how high it is in overall volume (and/or topcrash reports), and any information that is outside the average sample (i.e. only happening on specific OSes, specific Firefox versions, specific Graphics cards, or significant correlations with any modules or add-ons). Also, if comments tell anything about commonalities of actions and/or possible steps to reproduce, please include that. See the walkthrough below for some tips on how to get that. | ||
* Include any clues you have about this crash could be reproduced. When a developer can reproduce the crash, it's very likely they can find a fix as well. | * Include any clues you have about this crash could be reproduced. When a developer can reproduce the crash, it's very likely they can find a fix as well. | ||
* Examples of good crash bug reports: {{bug|1035168}} | * Examples of good crash bug reports: {{bug|1035168}} | ||
| Line 26: | Line 28: | ||
With those steps, I find that the product "Toolkit", component "Phishing Protection", so in the crash report, I clicked the "Toolkit" link next to "Report this bug in" within the Bugzilla section in about the middle of the page when scrolling down. Back on the crash report, I go to the top and click the "More Reports" link to get to a signature summary page to get more info about those crashes. | With those steps, I find that the product "Toolkit", component "Phishing Protection", so in the crash report, I clicked the "Toolkit" link next to "Report this bug in" within the Bugzilla section in about the middle of the page when scrolling down. Back on the crash report, I go to the top and click the "More Reports" link to get to a signature summary page to get more info about those crashes. | ||
Looking through those, I try to find properties that fall out of the ordinary (like only few Product versions being listed in the "Products" section, only very specific OSes listed, or specific graphics adapters, or much fewer installations than crashes listed in "Crashes per Install"), and looking at the list in the "Reports" tab, some things like the same address on all reports are interesting as well. All those should be listed in a comment on the bug report. | Looking through those, I try to find properties that fall out of the ordinary (like only few Product versions being listed in the "Products" section, only very specific OSes listed, or specific graphics adapters, or much fewer installations than crashes listed in "Crashes per Install"), and looking at the list in the "Reports" tab, some things like the same address on all reports are interesting as well. All those should be listed in a comment on the bug report. Posting a link to the "More Reports" page is usually a very good idea as well. | ||
Explaining the full hierarchy is not really possible, and it changes all the time in terms of components being added, some also retired. But I can give you a few pointers to the cornerstones, so to speak. Note that all this has grown organically over the 15+ years that the Mozilla project and Bugzilla have exited now, so some things might not be the same as one would design from scratch. | Explaining the full hierarchy is not really possible, and it changes all the time in terms of components being added, some also retired. But I can give you a few pointers to the cornerstones, so to speak. Note that all this has grown organically over the 15+ years that the Mozilla project and Bugzilla have exited now, so some things might not be the same as one would design from scratch. | ||