Question on automated crash reports
us...@domain.invalid
Newsgroups for Unread messages. This has resulted in an number of
automated crash reports in which I have attempted to document and narrow
the conditions leading up to the crash.
Can some shed some light on how automated crash reports are handled? I
assume someone looks at these periodically. Are these reports
automatically added to the bug tracker or are they recorded somewhere
else that is accessible? Should I followup on these reports and file a
more detailed bug report? This particular crash is easily reproduced
based on my limited testing and makes newsgroup reading quite hazardous
IMO.
David
Nathan Tuggy
http://crash-stats.mozilla.com/query/query?do_query=1&product=Thunderbird (this
is where the crash reports end up; they aren't automatically added to
Bugzilla).
Also, Thunderbird keeps a history of submitted crash reports; I believe
there is a way to view this, perhaps with an extension. Any tips from
the rest of the ng on viewing about:crashes in Thunderbird?
Definitely once you've found your crash reports (in Thunderbird or on
crash-stats) you should file a bug collecting them properly; ideally
link to the reports.
Thomas Stache
> Also, Thunderbird keeps a history of submitted crash reports; I believe
> there is a way to view this, perhaps with an extension. Any tips from
> the rest of the ng on viewing about:crashes in Thunderbird?
>
The "ViewAbout" add-on can help you out here:
https://addons.mozilla.org/en-US/thunderbird/addon/9695
Onno Ekker
> Try looking at the reports under
> http://crash-stats.mozilla.com/query/query?do_query=1&product=Thunderbird
> (this is where the crash reports end up; they aren't automatically
> added to Bugzilla).
>
> Also, Thunderbird keeps a history of submitted crash reports; I
> believe there is a way to view this, perhaps with an extension. Any
> tips from the rest of the ng on viewing about:crashes in Thunderbird?
Go to Tools | Options | General and set about:crashes as your
Thunderbird Start Page.
Onno
Ludovic Hirlimann
> I have been seeing crashes with RC1 Build 2 related to filtering
> Newsgroups for Unread messages. This has resulted in an number of
> automated crash reports in which I have attempted to document and narrow
> the conditions leading up to the crash.
That sounds nice - because sometimes with the automated crash repports
we get the crash and plenty of data with it, but sometime the data is
not enough to figure out what causes the crash - and thus fix it. So in
those case just file a bug report with the crash keyword- severity set
to critical. You'll get someone asking you more, like a crash id.
> Can some shed some light on how automated crash reports are handled? I
They are gathered by a bunch of processes called soccoro
(https://wiki.mozilla.org/Socorro) , which has a users queriable
interface at http://crash-stats.mozilla.com/.
> assume someone looks at these periodically. Are these reports
> automatically added to the bug tracker or are they recorded somewhere
> else that is accessible? Should I followup on these reports and file a
They are not automatically added to the bug tracker, but the dev and qa
team are looking closely at crash-stats and end up creating the missing
bugs.
> more detailed bug report? This particular crash is easily reproduced
> based on my limited testing and makes newsgroup reading quite hazardous
So you should gather the crash id see
http://kb.mozillazine.org/Breakpad on all the methods to achieve that,
find your crash on crash stats - if we already have a bug for that crash
, just got to the bug and add a comment telling us how we could
reproduce the crash. If not please file a new bug.
Hope my explanations are clear.
Ludo
--
Ludovic Hirlimann MozillaMessaging QA lead
http://www.spreadthunderbird.com/aff/79/2
Wayne Mery
> I have been seeing crashes with RC1 Build 2 related to filtering
> Newsgroups for Unread messages. This has resulted in an number of
> automated crash reports in which I have attempted to document and narrow
> the conditions leading up to the crash.
Steps are often lacking in bug reports, and can help resolve bugs faster
than just having a stack.
Also, making COMMENTS in automated crash reports are a good habit.
1. Context helps!
2. Not every crash has a good stack. Indeed, some have nothing.
COMMENTS IN CRASH REPORTER ARE GREAT. WE NEED MORE!
> I assume someone looks at these periodically.
It's unclear how many people monitor at crash-stats.com - perhaps a
dozen or two. What gets done probably varies - some of us follow the
activity as frequent as a few times a day or every day or two. Speaking
only for what I do, roughly the top 30-50 ranked crashes of alpha and
beta *point* releases receive good attention, the top 20 especially
close attention. The formula for the *released* 3.0, when that happens,
will probably be more like top 40-60. For nightly builds, I look mainly
at the top 20, and for big blips/major changes in ranking.
Note: The ranking of nightly build crashers generally does not match
anywhere close to point releases rankings. That, combined with limited
manpower, makes it hard-to-impossible to target nightly crashers in such
a way as to prevent a high percentage of "big" crashers from appearing
in point releases. However, that could change if many more people would
use nightlies on a continuous basis.
> Are these reports automatically added to the bug tracker
No.
> or are they recorded somewhere else that is accessible?
In bugzilla.mozilla.org (bmo) if someone filed a bug. (Conversely, not
every crash bug has stacks or signature. Depends on how the bug was
filed and the amount of followup, etc.)
The proper filing of a crash bugs is
summary: crash (couple words of description if possible) [@ <signature>]
keyword: crash
severity: critical (and whether it is a regression, etc)
example https://bugzilla.mozilla.org/show_bug.cgi?id=514945
crash [@ nsMsgSearchValidityTable::GetAvailable(int, int, int*)]
clicking search folder
> Should I followup on these reports and file a
> more detailed bug report? This particular crash is easily reproduced
> based on my limited testing and makes newsgroup reading quite hazardous
> IMO.
yes. Additional to the previous good responses, one can search bmo to
find crashes match your signature or description of symptoms.
In this case, searching on description of symptoms (bugs updated in last
60 days with the string "news" in the summary)
https://bugzilla.mozilla.org/buglist.cgi?chfieldto=Now;query_format=advanced;chfieldfrom=60d;short_desc=crash%20news;bug_severity=critical;short_desc_type=allwordssubstr;resolution=FIXED;resolution=---
Or by signature, you would search on the full sig
nsMsgSearchValidityTable::GetAvailable(int, int, int*)
If not found, search on the shorter
nsMsgSearchValidityTable::GetAvailable
because not all bugs have the full signature.
BTW, when searching crash-stats.com you want to use the exact, full sig
(which is default search) if possible.
David Taylor
>
> Hope my explanations are clear.
>
where the problem is repeatable or can be linked to specific actions.
One more questions...where to submit feature requests? The improvements
in TB3 are great and I would like to submit ideas for consideration. If
the process for setting up for development is not too hard I will
consider getting involved in the actual development myself.
Thanks,
David
David Taylor
>
> Steps are often lacking in bug reports, and can help resolve bugs faster
> than just having a stack.
>
> Also, making COMMENTS in automated crash reports are a good habit.
> 1. Context helps!
> 2. Not every crash has a good stack. Indeed, some have nothing.
> COMMENTS IN CRASH REPORTER ARE GREAT. WE NEED MORE!
>
involved in a number of open source projects and also in commercial
product beta testing. As a rule I include detailed steps and comment in
crash reports in the hope that they will be useful.
>
> > I assume someone looks at these periodically.
>
> It's unclear how many people monitor at crash-stats.com - perhaps a
> dozen or two. What gets done probably varies - some of us follow the
> activity as frequent as a few times a day or every day or two. Speaking
> only for what I do, roughly the top 30-50 ranked crashes of alpha and
> beta *point* releases receive good attention, the top 20 especially
> close attention. The formula for the *released* 3.0, when that happens,
> will probably be more like top 40-60. For nightly builds, I look mainly
> at the top 20, and for big blips/major changes in ranking.
>
> Note: The ranking of nightly build crashers generally does not match
> anywhere close to point releases rankings. That, combined with limited
> manpower, makes it hard-to-impossible to target nightly crashers in such
> a way as to prevent a high percentage of "big" crashers from appearing
> in point releases. However, that could change if many more people would
> use nightlies on a continuous basis.
>
Thanks for the clarification.
>
> The proper filing of a crash bugs is
> summary: crash (couple words of description if possible) [@ <signature>]
> keyword: crash
> severity: critical (and whether it is a regression, etc)
>
> example https://bugzilla.mozilla.org/show_bug.cgi?id=514945
> crash [@ nsMsgSearchValidityTable::GetAvailable(int, int, int*)]
> clicking search folder
>
OK. Is this documented anywhere by chance? This seems like useful
information other would want to know.
Thanks,
David
Ludovic Hirlimann
Bugzilla.mozilla.org is the place to find and add enhancement requests.
If you want to get involved you'll find some documentation on
developer.mozilla.org. Help will probably be available on
irc.mozilla.org in #maildev.
Andrew Sutherland
>> One more questions...where to submit feature requests? The improvements
>
> If you want to get involved you'll find some documentation on
> developer.mozilla.org. Help will probably be available on
> irc.mozilla.org in #maildev.
We are also trying out using the "ideas" mechanism on getsatisfaction:
http://getsatisfaction.com/mozilla_messaging
The getsatisfaction interface is a lot better suited than bugzilla for
discussion of ideas. It has limited threading support and allows people
to mark comments as "one of the best points" to highlight what people
think are good suggestions about an idea.
In contrast, bugzilla is better suited to tracking development effort
once there is a plan in place to implement an enhancement (and someone
to work it).
Andrew