Closed Bug 1411963 Opened 2 years ago Closed 2 years ago

Assertion failure: !sandwichResultValue.IsNull() (Result of GetBaseValue should not be null), at /builds/worker/workspace/build/src/dom/smil/nsSMILCompositor.cpp:96

Categories

(Core :: SVG, defect, P3)

55 Branch
defect

Tracking

()

RESOLVED FIXED
mozilla58
Tracking Status
firefox-esr52 --- unaffected
firefox56 --- wontfix
firefox57 --- wontfix
firefox58 --- fixed

People

(Reporter: jkratzer, Assigned: birtles)

References

(Blocks 1 open bug)

Details

(Keywords: assertion, testcase)

Attachments

(4 files)

Attached file trigger.html
Testcase found while fuzzing mozilla-central rev 64bab5cbb9b6.
Flags: in-testsuite?
Attached file log_minidump.txt
Attached file log_stderr.txt
INFO: Last good revision: 5175ea846fe007a1f13937a562faa1163c540e8f
INFO: First bad revision: 95e21766cd72bdda8da9bf8e8bd43909da3be861
INFO: Pushlog:
https://hg.mozilla.org/integration/autoland/pushloghtml?fromchange=5175ea846fe007a1f13937a562faa1163c540e8f&tochange=95e21766cd72bdda8da9bf8e8bd43909da3be861
Blocks: 1353208
Has Regression Range: --- → yes
Flags: needinfo?(bbirtles)
Priority: -- → P3
Version: 58 Branch → 55 Branch
That assertion was added in bug 1353208 so it's unlikely bug 1353208 actually regressed anything functionally, but I need to work out why the assertion fails.
This is failing because in nsSMILCSSValueType::ValueFromAnimationValue we hit the check for nsStyleUtil::CSPAllowsInlineStyle and return a null value.

In the changeset that introduced the assertion I added the comment:

  "...if we do call GetBaseValue the result should not be a null nsSMILValue (except in some OOM cases where we don't
really care if we miss a sample). This patch adds an assertion to check that GetBaseValue does, in fact, return a non-null value. (I checked the code and this appears to be the case. Even in error cases we typically return an empty nsSMILValue of a non-null type. For example, the early return in nsSMILCSSProperty::GetBaseValue() does this.)"

So clearly I missed one cases where we do, in fact, return a null value. Perhaps there are other cases too?

Provided all such cases represent exceptional error cases then perhaps it's ok if they return null. As I understand it, the consequence in that case is that if it happens as part of the initial sample, we will fail to set mForceCompositing to true in nsSMILCompositor::UpdateCachedBaseValue and, if nothing else sets it to true, we may miss fail to composite the first sample. 

However, on the first sample, surely something will set mForceCompositing to true since set we update it in nsSMILCompositor::GetFirstFuncToAffectSandwich() and will make it true if anything in the animation function has changed---at which point *everything* will have changed. So perhaps it's ok just to drop this assertion.
Assignee: nobody → bbirtles
Status: NEW → ASSIGNED
Flags: needinfo?(bbirtles)
Comment on attachment 8923708 [details]
Bug 1411963 - Drop assertion about GetBaseValue not returning null in nsSMILCompositor::ComposeAttribute;

https://reviewboard.mozilla.org/r/194846/#review200182

r=me
Attachment #8923708 - Flags: review?(dholbert) → review+
Pushed by bbirtles@mozilla.com:
https://hg.mozilla.org/integration/autoland/rev/ab9936483440
Drop assertion about GetBaseValue not returning null in nsSMILCompositor::ComposeAttribute; r=dholbert
https://hg.mozilla.org/mozilla-central/rev/ab9936483440
Status: ASSIGNED → RESOLVED
Closed: 2 years ago
Resolution: --- → FIXED
Target Milestone: --- → mozilla58
You need to log in before you can comment on or make changes to this bug.