Closed Bug 304769 Opened 17 years ago Closed 14 years ago

Incidents with "random hex addresses" at the top should have a signature based on the first *function* on the stack

Categories

(mozilla.org :: Talkback Server & Webtool, task)

task
Not set
normal

Tracking

(Not tracked)

RESOLVED WONTFIX

People

(Reporter: jruderman, Assigned: jay)

Details

(Whiteboard: [sg:want P4] [quicksearch 2.0])

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).
Whiteboard: [quicksearch 2.0]
Whiteboard: [quicksearch 2.0] → [sg:want P2] [quicksearch 2.0]
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.
Whiteboard: [sg:want P2] [quicksearch 2.0] → [sg:want P4] [quicksearch 2.0]
Breakpad should have this feature soon.  See bug 427083 and bug 411349.

WONTFIX for Talkback, I guess.
Status: NEW → RESOLVED
Closed: 14 years ago
Resolution: --- → WONTFIX
You need to log in before you can comment on or make changes to this bug.