Over 20% of Talkback reports have "random hex addresses" at the top of the stack*. Most of these have a real function as the second line of the stack. These should be grouped together, either as "foo::bar" (grouped with crashes with foo::bar at the top of the stack) or as "address, foo::bar" (grouped but separate from crashes with foo::bar at the top). I looked through some samples of crashes with "random hex addresses" at the top of the stack. There are several functions that show up often as the second line of the stack, such as nsXULDocument::AttributeChanged and JS_GetClass. These would probably be topcrashes if they were counted correctly. I'm also worried because these crashes are likely to be exploitable. I don't know what kinds of crashes they are, but I know they do cause the instruction pointer to go to semi-random addressess. *Percent of crashes have stack signatures starting with 0x: All: 22% ( 128206 / 565677 ) FirefoxTrunk: 21% ( 2515 / 11855 ) See also bug 304768, "Search talkback reports by stack (not just top line of stack)".

This is something that I've been thinking about doing for a while, so I am going to see if I can figure out a good way to do this in the next version of the Talkback query tools. In the mean time, we do have a Talkback report that groups incidents together based on the normal Talkback stack signature (as well the functions found in the first few frames of incidents whose stacks begin with a hex address). Check them out under "Smart Analysis" at http://talkback-public.mozilla.org/reports/firefox/ (or at any of the other Mozilla products' Talkback reports pages).

Bug 304768 addressed most of my concerns wrt security efforts; topcrash analysis isn't essential for attacking "scary crashes". It would still be good for stability efforts, which rely on knowing which crashes are the most frequent.

Breakpad should have this feature soon. See bug 427083 and bug 411349. WONTFIX for Talkback, I guess.