1261310 - crash in mozilla::gfx::Matrix4x4Typed<T>::operator*<T> (mozilla::gfx::Matrix4x4::operator* in older versions)

Status: RESOLVED WORKSFORME

(Core :: Graphics: Layers, defect, P3)

Description

[[:philipp]]

This bug was filed from the Socorro interface and is 
report bp-1ff5a511-ff9a-4228-8135-193392160331.
=============================================================
Crashing Thread (0)
Frame 	Module 	Signature 	Source
0 	xul.dll 	mozilla::gfx::Matrix4x4Typed<mozilla::gfx::UnknownUnits, mozilla::gfx::UnknownUnits>::operator*<mozilla::gfx::UnknownUnits>(mozilla::gfx::Matrix4x4Typed<mozilla::gfx::UnknownUnits, mozilla::gfx::UnknownUnits> const&) 	gfx/2d/Matrix.h
1 	xul.dll 	_cairo_path_fixed_init_copy 	gfx/cairo/cairo/src/cairo-path-fixed.c
2 	xul.dll 	_moz_cairo_clip_preserve 	gfx/cairo/cairo/src/cairo.c
3 	xul.dll 	mozilla::gfx::DrawTargetCairo::PushClipRect(mozilla::gfx::RectTyped<mozilla::gfx::UnknownUnits, float> const&) 	gfx/2d/DrawTargetCairo.cpp

this crash signature seems to be regressing in 45 (with bug 1069417). 

it is a rather low-volume signature, present on windows and android so far and it seems to happen repeatedly for particular machines/installations.

Comment 1

[Botond Ballo [:botond]]

This stack is corrupted: _cairo_path_fixed_init_copy does not call into Matrix4x4 code.

Comment 2

[Botond Ballo [:botond]]

I looked at some other crash reports with this signature, and they don't seem to have sensible stacks either.

For example, a common stack is the one in 3c8e4140-a460-4efd-b6df-8694c2160326:

0 	xul.dll 	mozilla::gfx::Matrix4x4Typed<mozilla::gfx::UnknownUnits, mozilla::gfx::UnknownUnits>::operator*<float>(mozilla::gfx::Point3DTyped<mozilla::gfx::UnknownUnits, float> const&) 	gfx/2d/Matrix.h
1 	xul.dll 	RefPtr<nsCSSValue::Array>::operator=<nsCSSValue::Array>(already_AddRefed<nsCSSValue::Array>&&) 	mfbt/RefPtr.h
2 	xul.dll 	mozilla::StyleAnimationValue::AddWeighted(nsCSSProperty, double, mozilla::StyleAnimationValue const&, double, mozilla::StyleAnimationValue const&, mozilla::StyleAnimationValue&) 	layout/style/StyleAnimationValue.cpp
3 	xul.dll 	mozilla::StyleAnimationValue::Interpolate(nsCSSProperty, mozilla::StyleAnimationValue const&, mozilla::StyleAnimationValue const&, double, mozilla::StyleAnimationValue&) 	layout/style/StyleAnimationValue.h
4 	xul.dll 	nsAnimationManager::BuildSegment(nsTArray<mozilla::AnimationPropertySegment>&, nsCSSProperty, mozilla::StyleAnimation const&, float, nsStyleContext*, mozilla::css::Declaration*, float, nsStyleContext*) 	layout/style/nsAnimationManager.cpp
5 	xul.dll 	nsAnimationManager::BuildAnimations(nsStyleContext*, mozilla::dom::Element*, mozilla::dom::AnimationTimeline*, nsTArray<RefPtr<mozilla::dom::Animation> >&) 	layout/style/nsAnimationManager.cpp
6 	xul.dll 	nsAnimationManager::CheckAnimationRule(nsStyleContext*, mozilla::dom::Element*) 	layout/style/nsAnimationManager.cpp

which is claiming that RefPtr::operator= is calling Matrix4x4::operator* (which it certainly is not).

Comment 3

[Botond Ballo [:botond]]

My guess is, this is unrelated to bug 1069417 - that bug just changed the signature of the crashes from 
  [@ mozilla::gfx::Matrix4x4::operator* ] 
to 
  [@ mozilla::gfx::Matrix4x4Typed<T>::operator*<T> ].

You can see versions prior to 45 crashing with the original signature:

https://crash-stats.mozilla.com/report/list?product=Firefox&range_unit=days&range_value=28&signature=mozilla%3A%3Agfx%3A%3AMatrix4x4%3A%3Aoperator*#tab-reports

Comment 4

[Milan Sreckovic [:milan] (needinfo for best results)]

(In reply to Botond Ballo [:botond] from comment #3)
> 
> You can see versions prior to 45 crashing with the original signature:
> 
> https://crash-stats.mozilla.com/report/
> list?product=Firefox&range_unit=days&range_value=28&signature=mozilla%3A%3Agf
> x%3A%3AMatrix4x4%3A%3Aoperator*#tab-reports

Some of these crashes go back to 35.

Comment 5

[u279076]

Apart from brief spikes on March 26, May 18, and July 12 this is averaging one report a day (5 reports in the last week against Firefox 47.0.*). As a note, we also see these crashes on Android and with Thunderbird but at even lower volume.

Comment 6

[Milan Sreckovic [:milan] (needinfo for best results)]

Very low volume crash, but let's keep tracking.

Comment 7

[Botond Ballo [:botond]]

Not actively working on this. (There's not much to go on given the sorts of stack traces we're seeing...)

Comment 8

[Wayne Mery (:wsmwk)]

Thunderbird crash rate is essentially zero

Comment 9

[Andrei Purice]

Marking this as Resolved > Worksforme since no other crashes with this signature have been reported in the last 6 months.