QA/Talkback/FAQ

What does it mean when I see the following error when submitting a crash incident: "The Agent is unable to connect to the server. Please check your Proxy Server settings or try again later."?

This error message is misleading. It does not always indicate a proxy related problem or mean that your incident has not been submitted to the Talkback Server.

We do know that a lot of people with slower connections (dialup, isdn) sometimes have timing issues and do not get a response from the Talkback server saying that their crash was successfully processed and stored. If you open up talkback.exe, find an Incident ID, and look it up with FastFind, chances are you will find your crash.

For more info, see Bug 210251, Comment 70.

How do I disable Talkback? (not recommended)

If you are having problems submitting crash incidents and continue to see the error discussed above, you can disable Talkback:

• Firefox/Thunderbird 1.5.x: Run talkback.exe (launches the Talkback Client) in the extensions directory (<application dir>/extensions/talkback@mozilla.org/components) and select Settings->Turn Agent Off.
• Firefox/Thunderbird 1.0.x: Run talkback.exe in the components directory (<application dir>/components) and select Settings->Turn Agent Off.

What data is sent with my crash incident?

There are a number of things that are included in the crash incident that is submitted to us. For more info, see the Old QFA page on mozilla.org (a bit outdated, but it shows you how to check what data will be sent with the Talkback Client after you crash). As far as I know, there is no other way to get a complete list until you trigger Talkback with a crash...at that point, clicking on the Details button will show you everything you might want to know (and allow you to uncheck items you don't want to send).

What additional information should I specify when submitting a crash incident?

Aside from the data collected automatically by Talkback, the crash dialog allows you to specify your email address, a URL, and comments about your crash. It is important that you provide us with as much useful information as you can to improve our ability to debug the issue. This includes the website you were visiting, any plugins or extensions you think might be related to the crash, what you were doing, etc. If you have been able to crash consistently, exact steps to reproduce the crash would be ideal!

• NOTE: If you submit your email address, it will be kept private (only Mozilla will be able to see that data). Personal information like IP and email addresses will not show up in public Talkback reports or query results.
• TIP: If you want to easily look up your own incidents, you can always add a unique string that you will remember in the URL or Comments field and then query for it with QuickSearch
  • e.g. in the Comments field I might enter something like: "Crash submitting a from at http://someurl [jpcrash20060130]" - that way, I could go search for "jpcrash" and get all of my incidents in one easy query.)

As a developer for Mozilla's SVG code I'd like to learn how to narrow crash results to crashes occuring on SVG content.

There are a number of ways to narrow down your query results to find specific types of crashes. For this case we'll look at SVG, but the same approach can be taken for any part of the code, feature, or component. Using the QuickSearch query tool at http://talkback-public.mozilla.org/talkback/fastfind.jsp , you can try the following:

• Search by a keyword in the Comments field (e.g. "svg"). This might not give you exactly what you want, but should provide a good number of crashes from people that were looking at SVG content...and from those results, you will be able to find some good URLs and comments to help look into SVG crashes.
• Search by a function in the code in the Stack Signature field (e.g. "nsSVGGradientFrame::GetNextGradient", "NPSVG3.dll"). You can even search for substrings (just make sure to select the proper pull down item for where in the complete string to search, like "Contains", "Begins With", etc.).
• Search by a website in the URL field (e.g. "http://www.w3.org/Graphics/SVG/"). This probably isn't the best option, unless you already know of a website that people have been crashing on consistently...but it can allow you to see what types of crashes are happening at certain popular websites.

Will you be looking at feedback from old builds? E.g. will you be looking at crash data from Firefox 1.5 in a month? Or is it only crashes in recent builds that are interesting?

This is a great question and the answer will explain exactly why we need more help from the community. To get a better understanding of which builds need to be looked at, you first need to understand which development branches exist and which product/project releases come off of them:

• Mozilla Trunk (FirefoxTrunk, ThunderbirdTrunk, MozillaTrunk [SeaMonkey])
• Mozilla 1.7/1.0 Aviary Branch (Firefox10, Thunderbird10, Mozilla17)
• Mozilla 1.8.0 Branch (Firefox15, Thunderbird15, SeaMonkey10)
• Mozilla 1.8 Branch (Firefox2, Thunderbird2, SeaMonkey11)

Looking at that list, I'll try to explain what type of crash analysis needs to be done for each:

1. The Trunk branches are the latest bleeding edge builds with a lot of new features and changes being checked in. These builds are great to look at to find regressions quickly and get them fixed right away. Since those trees are almost always open to the community of developers, people are encouraged to check in patches there first (possible fixes for various branches make their way to the Trunk first, bake for a while, and if things look good, they are ported to the branches that need the fix). We will always need more eyes on Trunk builds...since that is where most of the work is happening (but not necessarily where most of the Mozilla Corporation QA team spends it's time).

2. The Mozilla 1.0 Aviary branch is on it's way out since most of our users are switching to Firefox/Thunderbird 1.5.x (Mozilla 1.8.0 branch). People don't need to spend too much time looking at the crash data for builds/releases from this branch. However, we still support it and therefore need to look at it closely before and after any security point release. Firefox/Thunderbird 1.0.8 and Mozilla 1.7.13 are going to be the next releases, so it will be good to double check that they don't introduce any obvious regressions or bring down the overall stability when compared to Firefox/Thunderbird 1.0.7 and Mozilla 1.7.12.

3. The Mozilla 1.8.0 branch is perhaps the most important right now to focus our time on, since it is what most of our users are using (therefore more Talkback crash data to help us do better analysis). Firefox/Thunderbird 1.5 and all their future security releases (e.g Firefox 1.5.0.1 coming out soon) will be released off this branch, and therefore a lot of work is happening there. Since it just recently came out, now is the time for us to identify and log as many critical crash bugs we can find. There is no guarantee that they will be fixed right away, but we still need to work hard to dig for them, create testcases, find steps to reproduce, and work with the developers and community to find a fix. Chances are, if we find a fix soon, and it is a safe patch, it might get into the next security release. If people decide it's too risky for a security release, it will surely be fixed on the Trunk and most likely on the next release branch as well (Mozilla 1.8 branch).

4. The Mozilla 1.8 branch is for the next major version: Firefox/Thunderbird 2. While we continue to make Firefox/Thunderbird 1.5 more stable and secure, a lot of work is shifted over to this new branch. So, like the Trunk, this branch is where a lot of work is happening. It is another great place to watch crash data daily to catch any regressions and make sure we address new crashes as soon as possible. With Firefox/Thunderbird 1.5 reaching critical mass, this new 2.0 branch will become our main focus very soon. That means taking everything we have learned/gathered from Talkback crash data for 1.5 and trying to reproduce with 2.0 and see if the bug is still there, and if it is, try to get it fixed as soon as possible. Some crashes in 1.5 might not still be around in 2.0 (since a lot of code might have changed), so we need to make sure we identify what has carried over and what is new. This is perhaps the most challenging task, but by working together, we can make it a lot easier. :-)

As you can see, there are plenty of things to keep track of... and since I have not been able to keep up with everything on my own, I can use all the help I can get. A few people already do a lot of crash analysis on their own, but we can always use more eyes! If you have any questions, feel free to contact me. You can find me on IRC in #qa. Also, take some time to query for crash bugs in Bugzilla by looking for the "crash" and "topcrash" keywords...that should give you a good idea of what is out there now.

If there is a backlog of incidents waiting to be processed on http://talkback-public.mozilla.org/talkback/fastfind.jsp, can I look at the crash info for my recent incidents on my computer?

Unfortunatly, the data is not in a human-readable format on your local machine so there is no easy way to view it. You have to wait until the Talkback Server has processed your incident before looking it up by Incident ID or finding it in any query results.

I'd love to know if there is any trend analysis and/or reporting that I could do to help the coders identify the most common and/or problematic issues. Can I access the data and do analysis from my web browser?

Yes! There are already a number of reports for the various development branches and official releases that already organize the crash data and sort it by total number of incidents. This not only helps us focus our work on the most critical crashes, but allows you to easily browse the data to do whatever type of crash analysis you want. There are also query tools for you to create your own reports on the fly. All of this can be found at http://talkback-public.mozilla.org/talkback/fastfind.jsp.

• I will be writing up in more detail which reports are useful for different type of crash analysis soon. So keep an eye on the Talkback wiki page.

Does Talkback send what extensions/plugins you have installed? If not, should we list them in the comments?

No, Talkback does no automatically send us information about your particular extensions or plugins. Therefore, it is a great idea to include that type of information in the comments field when you're submitting a crash report (but usually only if you believe your crash is related or due to some extension or plugin). The comment field is for you to enter as much data as you want about the crash, so feel free to include anything and everything you care to tell us about. :-)

How can I induce a hung mozilla program to report via Talkback?

[Edit - partially answering my own question...] In Terminal.app, I tried guessing something and it worked:

kill -ABRT <PID>

where I found the <PID> with

ps -auxww|grep "PID\|thunderbird-bin"|grep -v grep

and it worked. Example:

MrE:~ elvey$ ps -auxww|grep thunderbird-bin
elvey    15276   0.1  2.4   200164  31572  ??  Ss   10:17AM   0:07.92 /Applications/Thunderbird1.5RC2.app/Contents/MacOS/thunderbird-bin -psn_0_45744129
elvey    15382   0.0  0.0    27804      4  p4  R+   10:24AM   0:00.00 grep thunderbird-bin
MrE:~ elvey$  kill -ABRT 15276

My Thunderbird has been hanging frequently (spinning wheel, Force Quit shows 'not responding'), but not crashing. Is there a kill signal I can send Thunderbird to get it to report what's up, i.e. a crashlog? HUP? INT? QUIT? ABRT? KILL? ALRM? TERM? (I'm on Mac OS X 10.4.6, Thunderbird 1.5.)

Whether doing this results in a useful talkback report is TBD. Having looked at what talkback planned to report, I'm guessing it won't be; the stack trace was empty.

Hmm. Thunderbird hung again, and I kill -ABRTed it, but this time talkback did nothing.  :(