MozillaZine

Quality Feedback Agent

From MozillaZine Knowledge Base

(Difference between revisions)
Revision as of 04:45, 23 October 2004
Jesse (Talk | contribs)

<-- Previous diff
Revision as of 21:05, 17 November 2004
Asqueella (Talk | contribs)
(talkback on windows + crash.exe for hung processes)
Next diff -->
Line 3: Line 3:
====How can I tell whether Talkback is installed?==== ====How can I tell whether Talkback is installed?====
-Crash. (?)+'''Windows''': Look in the ''components'' directory inside the directory you installed Mozilla/Firefox/Thunderbird to. If you have '''talkback.exe''' file there, you probably have Talkback installed.
====How can I get Talkback if it isn't already installed?==== ====How can I get Talkback if it isn't already installed?====
Line 37: Line 37:
====Can I submit Talkback reports for hangs?==== ====Can I submit Talkback reports for hangs?====
-While Talkback theoretically supports hang reports, I don't know how make it trigger for them. (?)+While Talkback theoretically supports hang reports, I don't know how make it trigger for them.
 + 
 +[http://viper.haque.net/~timeless/crash/ crash it] (?)

Revision as of 21:05, 17 November 2004

Contents

What is Talkback?

Talkback is a program that activates when Mozilla, Firefox, or Thunderbird crashes. It lets you send stack traces and other information to mozilla.org. This information helps developers make future versions of the software crash less.

How can I tell whether Talkback is installed?

Windows: Look in the components directory inside the directory you installed Mozilla/Firefox/Thunderbird to. If you have talkback.exe file there, you probably have Talkback installed.

How can I get Talkback if it isn't already installed?

Reinstall with Talkback. (?)

What is a stack trace?

A stack trace is a function call stack. For a crash, it shows the function in which the crash occurred, what function called that function, etc. This example Talkback crash report includes a stack trace.


How does mozilla.org use stack traces?

Stack traces are used in two ways.

Statistics are compiled based on the tops of the stack traces that all users submit. Periodacally, someone looks at these statistics and files bugs for the most frequent crashes, called "topcrashes".

A stack trace is an essential part of a bug report for any crash that is hard to reproduce. Stack traces often contain enough information about the causes of the crashes for developers to fix them even if they can't reproduce the crash based on your "somtimes crashes when..." report, steps to reproduce, or testcase.


Once I submit a Talkback report, how can I get a stack trace?

First, run firefox\components\talkback.exe to get the Talkback ID. Then, paste the ID into Talkback FastFind. This will let you see a stack trace.

(Where is talkback.exe on other platforms?)


If I submit a crash report, should I still file a bug report in Bugzilla?

Yes. Unless you file a bug, your crash report will only be used in statistics to find topcrashes.


How can I submit a useful bug report for a crash?

First, try to find existing bug reports about your crash. Search based on the signature (listed separately in the Talkback report, usually the name of the top function in the stack trace). For example, if the signature is nsXPCWrappedJSClass::CheckForException, search for "CheckForException". If you find a bug with a similar stack and the same steps-to-reproduce, just vote for the bug. But don't assume two crash bugs are the same just because the crashes happen with the same function at the top of the stack.

When submitting your bug, you can include the talkback ID in your bug report instead of the full stack trace. In your summary for the bug, include the name of the function. For example, "Crash [@ CSSStyleRuleImpl::DeclarationChanged] toggling visibility value via DOM Inspector".


Can I submit Talkback reports for hangs?

While Talkback theoretically supports hang reports, I don't know how make it trigger for them.

crash it (?)


Should I file the crash as a security-sensitive bug?

Usually not. If the crash is just a denial of service (DoS), Mozilla's security group probably isn't interested.

If the crash is in NSS or NSPR, it should be considered a security hole. These components are also used by some server software, so crashes in these components are considered security holes even if the most an attacker could do is cause a DoS.

If the top of the stack is a random memory address instead of a function name, that means Mozilla crashed when trying to jump to an incorrect address. If the attacker can control the address Mozilla jumps to, he can probably cause Mozilla to execute arbitrary machine code instead of crashing. In addition to looking at the stack, you can inspect the C++ code by clicking the links in the Talkback report.

If you file the bug as security-sensitive, say why you did, e.g. "I'm filing this crash bug as security-sensitive because it is in NSS and NSS maintainers consider DoSes to be security holes".


What information is in Talkback reports other than what I can see in the public-facing database?

I don't know. (?)


More information