crash stacks broken on windows debug reftests

NEW
Unassigned

Status

2 years ago
7 months ago

People

(Reporter: dbaron, Unassigned)

Tracking

Trunk

Firefox Tracking Flags

(firefox52 wontfix)

Details

Bug 1306514 points to a windows debug test log in which the crash stack is broken.  (Assertion stacks are fine, though.)

Steps to reproduce:
 look at the PROCESS-CRASH line in the log linked from bug 1306514

Expected results: useful crash stacks

Actual results: xul.dll + offset, which is useless



Any idea who is responsible for this?
Flags: needinfo?(ryanvm)
Flags: needinfo?(ted)
Redirecting to people who still watch the trees on a regular basis.
Flags: needinfo?(wkocher)
Flags: needinfo?(ryanvm)
Flags: needinfo?(cbook)
gps said he thought it was likely a regression from work ted was doing.
This particular minidump is slightly broken. It's missing the CodeView record for xul.dll, which is used to locate the symbol file:
  (code_file)                     = "c:\slave\test\build\application\firefox\xul.dll"
  (code_identifier)               = "57ED739A50f8000"
  (cv_record)                     = (null)
  (misc_record)                   = (null)
  (debug_file)                    = ""
  (debug_identifier)              = ""

The CV record has the GUID that Breakpad uses as the debug_identifier. On Windows we just use MinidumpWriteDump to write minidumps, so this isn't something we can fix. In the past we noticed this would happen in OOM situations, because MinidumpWriteDump presumably mmaps the files to get this info, and we had the crashreporter code reserve a block of memory on startup and free it before the dump gets written. Assuming that's still in place I don't have any better ideas.
Flags: needinfo?(ted)

Updated

2 years ago
Flags: needinfo?(cbook)

Updated

2 years ago
Flags: needinfo?(wkocher)
Too late for firefox 52, mass-wontfix.
status-firefox52: affected → wontfix
Per comment #3, this only impacts some crashes.

Since this has been idle for ~7 months, lowering severity.

dbaron, others can re-justify severity as appropriate.
Severity: blocker → normal

Updated

7 months ago
Product: Core → Firefox Build System
You need to log in before you can comment on or make changes to this bug.