EXCEPTION_PRIV_INSTRUCTION crash in nsIFrame::GetUsedBorder called from nsDisplayBorder::AllocateGeometry due to AMD CPU bug

NEW
Unassigned

Status

()

Core
CSS Parsing and Computation
--
critical
2 years ago
9 months ago

People

(Reporter: dbaron, Unassigned)

Tracking

({crash, topcrash})

unspecified
x86
Windows NT
crash, topcrash
Points:
---

Firefox Tracking Flags

(platform-rel -, firefox46- affected)

Details

(Whiteboard: [platform-rel-AMD], crash signature)

Attachments

(2 attachments)

(Reporter)

Description

2 years ago
This bug was filed from the Socorro interface and is 
report bp-f95190c4-cc96-402b-b3ab-f41032160420.
=============================================================

In the list of topcrashes for the release candidates for 46 I noticed these crashes in nsIFrame::GetUsedBorder, called from nsDisplayBorder::AllocateGeometry:
https://crash-stats.mozilla.com/signature/?product=Firefox&version=46.0b99&signature=nsIFrame%3A%3AGetUsedBorder

All of the crashes so far occur in build 3 of the release candidate (build ID 20160418114253).  All but 1 of the crashes are on AMD processors affected by bug 772330, and that one crash has a crash address that was a different address within GetUsedBorder (i.e., a crash address not ending in b0c3).

Kyle and I just spent a few hours debugging one instance of this crash (the one linked at the top of this comment) and concluded that this is most likely another occurrence of the notorious AMD processor bug (bug 772330), although we don't fully understand the conditions in the description of the processor bug.

The symptoms are that we call nsIFrame::GetUsedBorder from the nsIFrame::GetContentRectRelativeToSelf call inlined within the nsDisplayItem::GetContentRect call inlined within nsDisplayBorderGeometry constructor inlined within nsDisplayBorder::AllocateGeometry.  This call seems to be made in a reasonable way, but at some point we jump to an unaligned address within GetUsedBorder (in a part of GetUsedBorder that is inlining a call to StyleBorder() near the end of the function) and crash with EXCEPTION_PRIV_INSTRUCTION because that is not properly instruction-aligned.
(Reporter)

Comment 1

2 years ago
Created attachment 8744139 [details]
analysis of (1) memory on stack in the GetUsedBorder call and (2) disassembly of code in nsDisplayBorder::AllocateGeometry
(Reporter)

Comment 2

2 years ago
Created attachment 8744140 [details]
analysis of disassembly of nsIFrame::GetUsedBorder

Comment 3

2 years ago
[Tracking Requested - why for this release]: Affects Fx46 based on DBaron's email to r-d. Liz, fyi so you don't miss it.
status-firefox46: --- → affected
tracking-firefox46: --- → ?
Flags: needinfo?(lhenry)
(Reporter)

Comment 4

2 years ago
I think things are probably OK, since this is build-specific, and we're planning to ship build 5 (or later?!) rather than build 3.

Comment 5

2 years ago
Those AMD crashes were always build-specific, and we knew that the workaround that dmajor put in will not always help but it held up pretty well so far. It's surely interesting and noteworthy that we have a reoccurrance here, but I guess it's not very actionable - and thankfully does only affect this one build.

Thanks for finding out about this!
Thanks for letting us know. I don't think we need to track this bug for now.
tracking-firefox46: ? → -
Flags: needinfo?(lhenry)
platform-rel: --- → ?
Whiteboard: [platform-rel-AMD]
platform-rel: ? → -
You need to log in before you can comment on or make changes to this bug.