1036657 - "Assertion failure: intercept.HasPositiveWCoord()"

Status: RESOLVED FIXED

(Core :: Graphics, defect)

Description

[Jesse Ruderman]

Attachment: testcase

Assertion failure: intercept.HasPositiveWCoord(), at gfx/thebes/gfx3DMatrix.cpp:821

This assertion was just added, in bug 1031948.

Comment 1

[Jesse Ruderman]

Attachment: stack

Comment 2

[Carsten Book [:Tomcat]]

also found on http://letour.yorkshire.com/stage-1/race-day-photos as example

Comment 3

[Benoit Jacob [:bjacob] (mostly away)]

My bad for not catching this during review.

I can reproduce; intercept.w is NaN.

That is because the points that we are working on have 'inf' coordinates in this testcase. Even if they hadn't, in ComputePerspectivePlaneIntercept we do:

  float w = 0.00001f;
  float t = (w - aFirst.w) / (aSecond.w - aFirst.w);

  // Use t to find the remainder of the components
  return aFirst + (aSecond - aFirst) * t;

So we could easily end up with NaN if the computation of t were a 0/0 division.

Finally, that assertion could also fail if loss of precision caused w to be exactly zero.

All in all, I think that that assertion is bad and needs to be removed.

Note that MOZ_ASSERT already prevents people from accidentally writing assertions on floating-point values being nonzero (MOZ_ASSERT(x)) as those are most often bad assertions. But here we are not in a trivial case that MOZ_ASSERT's static checking can catch for us.

Comment 4

[Benoit Jacob [:bjacob] (mostly away)]

Attachment: remove-bad-assert

Comment 5

[Benoit Jacob [:bjacob] (mostly away)]

https://hg.mozilla.org/integration/mozilla-inbound/rev/9d4a18a375d0

Comment 6

[Wes Kocher (:KWierso) (Not reading bugmail; email directly if needed)]

https://hg.mozilla.org/mozilla-central/rev/9d4a18a375d0