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.
Created attachment 8744139 [details] analysis of (1) memory on stack in the GetUsedBorder call and (2) disassembly of code in nsDisplayBorder::AllocateGeometry
[Tracking Requested - why for this release]: Affects Fx46 based on DBaron's email to r-d. Liz, fyi so you don't miss it.
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.
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.