Quality Feedback Agent

From MozillaZine Knowledge Base
Jump to navigationJump to search

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.

Timeless has written a program called crash.exe that can be used to force Firefox to crash, but it makes Firefox crash in a new thread, so it doesn't create a useful stack trace for hangs. A future version of crash.exe might let you specify a thread to crash, which could be used in combination with Sysinternals Process Explorer to make the hanging thread crash.


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