Closed Bug 1745732 Opened 4 years ago Closed 3 years ago

improve signature for crash reports with "EMPTY: no crashing thread identified; OK" signature

Categories

(Socorro :: Processor, task, P2)

Product:
Socorro
Component:
Processor
Type:
task

Tracking

(Not tracked)

Status:
RESOLVED FIXED

People

(Reporter: willkg, Assigned: willkg)

Details

Attachments

(1 file)

pr 6191: bug 1745732: improve signatures for crash reports with thread index issues
53 bytes, text/x-github-pull-request
Details | Review

This crash report has no crashing thread set so we get an unhelpful signature for it:

https://crash-stats.mozilla.org/report/index/16c47498-0b7e-4a1d-b265-548bd0211213

Here's the signature report with other similar reports:

https://crash-stats.mozilla.org/signature/?product=Firefox&signature=EMPTY%3A%20no%20crashing%20thread%20identified%3B%20OK&_columns=date&_columns=product&_columns=version&_columns=build_id&_columns=platform&_columns=reason&_columns=address&_columns=install_time&_columns=startup_crash&_sort=-date&page=1#reports

Is the minidump missing information? Is this a bug in the crash reporter client?

Is the minidump malformed or corrupt? Is there something we can surface in minidump-stackwalk?

The minidump is seemingly well-formed, but the "crashing thread_id" defined by MINIDUMP_EXCEPTION does not appear in the MinidumpThreadList. Both rust-minidump and breakpad therefore produce a report without a crashing_thread field.

That said, the MinidumpThreadList is kind of a mess. Only 4 threads, and half of them are missing their stack memory and registers (????). Seems like the client was having a real struggle to get this thing out the door, so it wouldn't surprise me if it dropped a bunch of threads on the ground.

(note to self: this is like the one case where rust-minidump omits a field instead of making it null, due to a quirk in how we emit it in a second pass.)

MINIDUMP_EXCEPTION
  thread_id                                  = 0x16dc
  exception_record.exception_code            = 0x80000003
  exception_record.exception_flags           = 0x0
  exception_record.exception_record          = 0x0
  exception_record.exception_address         = 0x69bb957c
  exception_record.number_parameters         = 3
  exception_record.exception_information[ 0] = 0x0
  exception_record.exception_information[ 1] = 0xffffffff8557ed48
  exception_record.exception_information[ 2] = 0x69ade34c
  thread_context.data_size                   = 716
  thread_context.rva                         = 0x4614

MinidumpThreadList
  thread_count = 4

thread[0]
MINIDUMP_THREAD
  thread_id                   = 0x17b4
  suspend_count               = 4294967295
  priority_class              = 0x20
  priority                    = 0x0
  teb                         = 0x0
  stack.start_of_memory_range = 0x0
  stack.memory.data_size      = 0x0
  stack.memory.rva            = 0x0
  thread_context.data_size    = 0x2cc
  thread_context.rva          = 0x48e0

CONTEXT_X86
...
No stack





thread[1]
MINIDUMP_THREAD
  thread_id                   = 0x134c
  suspend_count               = 4294967295
  priority_class              = 0x20
  priority                    = 0x0
  teb                         = 0x0
  stack.start_of_memory_range = 0x0
  stack.memory.data_size      = 0x0
  stack.memory.rva            = 0x0
  thread_context.data_size    = 0x2cc
  thread_context.rva          = 0x0

  (no context)

No stack





thread[2]
MINIDUMP_THREAD
  thread_id                   = 0xf98
  suspend_count               = 4294967295
  priority_class              = 0x20
  priority                    = 0x0
  teb                         = 0x7ff9a000
  stack.start_of_memory_range = 0x90bf914
  stack.memory.data_size      = 0x6ec
  stack.memory.rva            = 0x61dd
  thread_context.data_size    = 0x2cc
  thread_context.rva          = 0x4bac

CONTEXT_X86
...
Stack
...





thread[3]
MINIDUMP_THREAD
  thread_id                   = 0x151c
  suspend_count               = 4294967295
  priority_class              = 0x20
  priority                    = 0x0
  teb                         = 0x0
  stack.start_of_memory_range = 0x0
  stack.memory.data_size      = 0x0
  stack.memory.rva            = 0x0
  thread_context.data_size    = 0x2cc
  thread_context.rva          = 0x0

  (no context)

No stack

Do you think it would be "better" if Socorro generated a signature based on thread 0 in cases where no crashing thread was identified?

I think that's a good heuristic for firefox, since that's often the main thread, but I'm not sure if the signal-noise is worthwhile overall?

Testing what bugzilla does with emoji because that's important right now: 😖

This change gets us signatures like this:

Crash id: 2cd08bb2-fbbb-4a7f-99b3-8dfb40220908
Original: EMPTY: no crashing thread identified; MissingThreadList
New:      EMPTY: no frame data available; MissingThreadList
Same?:    False
Notes:    (1)
          SignatureGenerationRule: CSignatureTool: no frame data for crashing thread (0)

Crash id: 2122ea3e-d9c9-4354-971e-75c4e0220908
Original: OOM | large | EMPTY: no crashing thread identified; EmptyMinidump
New:      OOM | large | EMPTY: no frame data available; EmptyMinidump
Same?:    False
Notes:    (1)
          SignatureGenerationRule: CSignatureTool: no frame data for crashing thread (0)

Crash id: 7b18389e-f980-47e8-be98-947660220908
Original: EMPTY: no crashing thread identified; OK
New:      KiFastSystemCallRet
Same?:    False
Notes:    (1)
          SignatureGenerationRule: CSignatureTool: no frame data for crashing thread (0)

This got pushed to prod in bug #1790838 just now. Marking as FIXED.

Status: ASSIGNED → RESOLVED
Closed: 3 years ago
Resolution: --- → FIXED
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: