Open
Bug 1306515
Opened 8 years ago
Updated 2 years ago
crash stacks broken on windows debug reftests
Categories
(Firefox Build System :: General, defect)
Firefox Build System
General
Tracking
(firefox52 wontfix)
NEW
Tracking | Status | |
---|---|---|
firefox52 | --- | wontfix |
People
(Reporter: dbaron, Unassigned)
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)
Reporter | ||
Updated•8 years ago
|
Flags: needinfo?(ted)
Comment 1•8 years ago
|
||
Redirecting to people who still watch the trees on a regular basis.
Flags: needinfo?(wkocher)
Flags: needinfo?(ryanvm)
Flags: needinfo?(cbook)
Reporter | ||
Comment 2•8 years ago
|
||
gps said he thought it was likely a regression from work ted was doing.
Comment 3•8 years ago
|
||
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•8 years ago
|
Flags: needinfo?(cbook)
Flags: needinfo?(wkocher)
Comment 4•8 years ago
|
||
Another recent instance:
https://treeherder.mozilla.org/logviewer.html#?job_id=5369228&repo=mozilla-central
Comment 5•8 years ago
|
||
Too late for firefox 52, mass-wontfix.
Comment 6•8 years ago
|
||
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 years ago
|
Product: Core → Firefox Build System
Updated•2 years ago
|
Severity: normal → S3
You need to log in
before you can comment on or make changes to this bug.
Description
•