Intermittent browser/components/contextualidentity/test/browser/browser_windowOpen.js | application crashed [@ fun_trace]
Categories
(Core :: JavaScript: GC, defect, P3)
Tracking
()
People
(Reporter: intermittent-bug-filer, Unassigned)
References
(Blocks 3 open bugs)
Details
(Keywords: crash, intermittent-failure, stalled)
Crash Data
Comment hidden (Intermittent Failures Robot) |
Comment 2•6 years ago
|
||
Moving these bugs (intermittent test failures with crashes) out of P5.
Comment 3•6 years ago
|
||
While the intermittent did not reproduce since more than a year, there is no other bug about this crash signature.
However, the volume of crashes for this signature is low.
Looking at a 6 month backlog of crashes I see random crash addresses, including 2/356 which have the JS_SWEPT_TENURED_PATTERN value.
Paul, an idea if this crash report would be actionable in any way?
Comment 4•6 years ago
|
||
It's unlikely to be actionable unless someone can reproduce it in rr and we can replay it.
The crash signature seems to pull up lots of different kinds of bugs, and like you say, various crash addresses. There's probably more than one bug (or badram since the volume is low). I'd say it'd be pretty hard to take any action (unless someone has an rr recording) and I'd even say there's a good chance this is just in the background noise of random crashes.
I'm going to move it back to P5, it's not worth our time unless more information comes up.
Comment 5•5 years ago
|
||
Don't mark intermittent crashes as P5s. We want them to go to triage owners.
Comment 7•5 years ago
|
||
We have a PHC crash report with this signature: https://crash-stats.mozilla.com/report/index/259c9162-29bd-4442-b117-f992f0190817
PHC says that the page in question has never been allocated. This suggests a wild write that coincidentally happened to hit one of PHC's pages.
Comment 8•5 years ago
|
||
There's not much we can do with that either. Some bad value got written into an object, copied onto the mark stack and then popped off and de-referenced (I think). But we don't know where that bad value came from initially.
Maybe PHC can tell us that, if it can that'd be great.
I'm not so sure about "wild".
788 00000001`843d57ff 4889d8 mov rax,rbx
788 00000001`843d5802 48250000f0ff and rax,0FFFFFFFFFFF00000h
788 00000001`843d5808 488b88f8ff0f00 mov rcx,qword ptr [rax+0FFFF8h] ; crash here, rbx == 0x400, rax = 0
That's the calculation of the address of Chunk::trailer
. If I'm following the inlining correctly, this is isOwnedByOtherRuntime(..., 0x400)
inside ShouldMark
. It seems more likely that the 0x400 was arrived at by a null pointer than a garbage value.
Updated•3 years ago
|
Updated•2 years ago
|
Comment 10•2 years ago
|
||
Since the crash volume is low (less than 15 per week), the severity is downgraded to S3
. Feel free to change it back if you think the bug is still critical.
For more information, please visit auto_nag documentation.
Description
•