1468888 - Crash in mozilla::dom::SVGViewportElement::IsInner

Status: RESOLVED WORKSFORME

(Core :: General, defect, P4)

Description

[[:philipp]]

This bug was filed from the Socorro interface and is
report bp-e1204a4c-6de4-499f-9395-deb500180614.
=============================================================

Top 10 frames of crashing thread:

0 xul.dll mozilla::dom::SVGViewportElement::IsInner dom/svg/SVGViewportElement.h:162
1 xul.dll mozilla::dom::SVGViewportElement::PrependLocalTransformsTo dom/svg/SVGViewportElement.cpp:276
2 xul.dll nsSVGOuterSVGAnonChildFrame::IsSVGTransformed layout/svg/nsSVGOuterSVGFrame.cpp:1021
3 xul.dll nsDisplayListBuilder::AutoBuildingDisplayList::AutoBuildingDisplayList layout/painting/nsDisplayList.h:1073
4 xul.dll nsIFrame::BuildDisplayListForChild layout/generic/nsFrame.cpp:3721
5 xul.dll nsContainerFrame::BuildDisplayListForNonBlockChildren layout/generic/nsContainerFrame.cpp:388
6 xul.dll nsSVGOuterSVGFrame::BuildDisplayList layout/svg/nsSVGOuterSVGFrame.cpp:788
7 xul.dll nsIFrame::BuildDisplayListForChild layout/generic/nsFrame.cpp:3861
8 xul.dll nsFlexContainerFrame::BuildDisplayList layout/generic/nsFlexContainerFrame.cpp:2376
9 xul.dll nsIFrame::BuildDisplayListForChild layout/generic/nsFrame.cpp:3861

=============================================================

this crash signature is spiking up on firefox 60.0.2 64bit builds on windows - commonly with a wild pointer address. german and russian locales seem to be a bit over-represented in crash reports.
the esr build doesn't seem to be affected, so this might point to some build-specific oddity.

Comment 1

[Randell Jesup [:jesup] (needinfo me)]

This spiked in 60.0.2 with new crash signatures

It appears to be an incorrect branch (call) ending up on a wrong instruction boundary.

dmajor helped me realize that all the crashes are on either family 6 model 58 stepping 9 | 4, or family 6 model 58 stepping 9 | 8

This appears to be a processor bug, perhaps triggered by PGO or other compilation changes in 60.0.2.   The volume is annoying but not high (20-30 per day).  We could respin or analyze to try to figure out how to sidestep the CPU bug... I'm not sure it's worthwhile.  This may (or may not) disappear in the next spin or release.

Comment 2

[Liz Henry (:lizzard) (relman/hg->git project)]

OK. I'll track it so that it will show up in queries if we see it on 61 or 62 release.

Comment 3

[Maire Reavy [:mreavy]]

Hey Liz, since you're explicitly tracking this, I'm going to assign thisbug  to you until we know if it's a problem or not.  If it's a problem, please needinfo me, and I'll figure out next steps.

Comment 4

[Liz Henry (:lizzard) (relman/hg->git project)]

There's no chance I'm going to fix it, and I don't want there being someone assigned to stop someone else from taking it on. For stuff where I might want to keep an eye especially on something outside of triage queries I'd prefer to use needinfo -

Comment 5

[Mats Palmgren (inactive)]

Comment 1 seems very plausible to me given that all 60.0.2 crashes are from the same CPU model in two different steppings.

Comment 6

[Mats Palmgren (inactive)]

-> General, since it's not a bug in our SVG implementation per se.

Comment 7

[Liz Henry (:lizzard) (relman/hg->git project)]

No crashes reported yet in 61 release, 62 beta/dev ed, or 63. There was one crash reported a couple of weeks ago from 61 beta 14. 

That seems promising, but I'll leave this marked ? and tracked for a while longer, so that we'll check up on this again in a week or so. It's still early in the 61 release.

Comment 8

[Daniel Veditz [:dveditz]]

This crash exploded with the release of 60.0.2 -- apart from 7 scattered crashes before then this boomed on Jun 7, the day after the release. There are no crashes with 60.0 or 60.0.1, and only a few in 61.0 releases. It tapered off starting end of June(61.0 released June 26) and there have been no crashes since July 25 (even though plenty of 60.0.2 was still out there).

There were only a few bugs fixed in 60.0.2 and nothing SVG-related. The theory in comment 1 seems plausible.