667324 - "ABORT: We expect aDirtyRect to be non-null" with <foreignObject> in <pattern>

Status: RESOLVED FIXED

(Core :: SVG, defect)

Description

[Jesse Ruderman]

Attachment: testcase (crashes Firefox when loaded)

###!!! ABORT: We expect aDirtyRect to be non-null: 'aDirtyRect', file layout/svg/base/src/nsSVGForeignObjectFrame.cpp, line 200

Comment 1

[Jesse Ruderman]

Attachment: stack trace

Comment 2

[Jesse Ruderman]

Only crashes debug builds. I guess opt builds hit one of the early returns before doing a null deref.

Comment 3

[Jesse Ruderman]

The first bad revision is:
changeset:   f23ef87dcfb3
user:        Robert Longson
date:        Sun Apr 24 20:55:58 2011 +0100
summary:     Bug 620274 - nsSVGForeignObjectFrame::PaintSVG null checks aDirtyRect when it is always non-null r=dholbert

Comment 4

[Daniel Holbert [:dholbert]]

(That first-bad-cset makes sense -- that's the bug that added the assertion.)

So, the null aDirtyRect comes from 2 stacklevels up, here:
> 325       nsSVGUtils::PaintFrameWithEffects(&tmpState, nsnull, kid);
http://mxr.mozilla.org/mozilla-central/source/layout/svg/base/src/nsSVGPatternFrame.cpp#325

...and PaintFrameWithEffects calls
> svgChildFrame->PaintSVG(aContext, aDirtyRect);
and in this case svgChildFrame is a nsSVGForeignObjectFrame.

There are analogous PaintFrameWithEffects(... nsnull...) calls in nsSVGMaskFrame.cpp and nsSVGMarkerFrame.cpp, too -- I imagine those might also hit this problem.

So, it looks like bug 620274 comment 1 was overly optimistic. :)

I think we probably want to back out bug 620274, and then add a null check around the code that timeless highlighted in the first comment there...

(In reply to comment #2)
> Only crashes debug builds. I guess opt builds hit one of the early returns
> before doing a null deref.

Yeah -- if I replace the ABORT_IF_FALSE to WARN_IF_FALSE, then my debug build loads the testcase fine, too.  It takes the first return from PaintSVG, under "if (IsDisabled())" (which checks for an empty mRect, which we have in this case.)

Comment 5

[Robert Longson [:longsonr]]

Just swapping the IsDisabled and ABORT lines would fix this, although I'm worried that we've not done a reflow so that foreignObjects in patterns don't really work properly and never have.

Backing out f23ef87dcfb3 seems a good start though.

Comment 6

[Robert Longson [:longsonr]]

backed out bug 620274

Comment 7

[Phil Ringnalda (:philor)]

https://hg.mozilla.org/mozilla-central/rev/24365794891f