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?
David Baron :dbaron: 🏴 ⌚UTC-8 (if account gets disabled due to email bounces, ask a bugzilla admin to reenable it)(Reporter)
2 years ago
Redirecting to people who still watch the trees on a regular basis.
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.
Another recent instance: https://treeherder.mozilla.org/logviewer.html#?job_id=5369228&repo=mozilla-central
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
You need to log in before you can comment on or make changes to this bug.