Open Bug 1428235 Opened 6 years ago Updated 1 year ago

Intermittent browser/components/contextualidentity/test/browser/browser_windowOpen.js | application crashed [@ fun_trace]

Categories

(Core :: JavaScript: GC, defect, P3)

defect

Tracking

()

People

(Reporter: intermittent-bug-filer, Unassigned)

References

(Blocks 3 open bugs)

Details

(Keywords: crash, intermittent-failure, stalled)

Crash Data

Blocks: GCCrashes

Moving these bugs (intermittent test failures with crashes) out of P5.

Priority: P5 → --

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?

Flags: needinfo?(pbone)
Priority: -- → P3

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.

Flags: needinfo?(pbone)
Priority: P3 → P5

Don't mark intermittent crashes as P5s. We want them to go to triage owners.

Priority: P5 → --

Intermittent GC crash. Marking stalled.

Keywords: stalled
Priority: -- → P3

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.

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.

QA Whiteboard: qa-not-actionable
Severity: critical → S2

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.

Severity: S2 → S3
You need to log in before you can comment on or make changes to this bug.