Quality Feedback Agent

From MozillaZine Knowledge Base
Jump to navigationJump to search

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

Installing

Talkback is usually bundled with Firefox/Thunderbird/Mozilla Suite. However to install it you may need to do a "Custom" installation and select "Quality Feedback Agent" component manually.

Q: How can I tell whether Talkback is installed?
A: If you're using Firefox 1.0.x, look in the "components" subdirectory of the application directory. If you have "talkback.exe" file there, you almost certainly have Talkback installed. If you're using Firefox 1.5.x, look in Extension manager for an extension named Talkback.

Q: How can I get Talkback if it isn't already installed?
A: Probably the only way to do this is to reinstall with Talkback.

Q: I have Talkback installed, but it doesn't appear to work!
A: Make sure you turned it on. The first time you crash, a window appears asking whether you want to turn the agent on or off. If you have chosen to turn it off, you still can turn Talkback back on by running it manually (the executable in "components" folder) and selecting "Settings -> Turn Agent on".

How does mozilla.org use Talkback data?

Talkback data is used in two ways:

  • Statistics are compiled based on the tops of the stack traces that all users submit. Periodically, someone looks at these statistics and files bugs for the most frequent crashes, called "topcrashes".
  • A stack trace, which can be extracted from a Talkback report, 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 "sometimes crashes when..." report, steps to reproduce, or testcase.

Stack traces

What is a stack trace?

A stack trace is a function call stack, often helpful for understanding the cause of a bug. For a crash, it shows the function in which the crash occurred, what function called that function, etc.

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

Each report the Agent sends has its own Talkback ID, which you can see in Talkback's window. The ID looks like "TB4895329Q" and this is what you need to post to bugzilla when you're asked to post a talkback ID.

However if you're curious, you can see the stack trace of your crash by entering your Talkback ID into Talkback FastFind.

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.

Talkback and Bugzilla

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 topcrashers.

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

Once you reproduced the crash, send the Talkback report, then copy the ID from the Talkback window. (On some platforms, you must run talkback.exe before you'll see the Talkback window.) Go to Talkback FastFind and enter your ID. If everything works correctly, you'll get a page with report details.

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 similar steps to reproduce or URL, 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".

It's also important to pick the right component for your crash.

If you can figure out easy steps to reproduce and create a small testcase, do so!

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. Even if the address appears to be random, the attacker might be able to put enough copies of his code throughout memory with nop slides to exploit the crash. 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".

More information