386566 - Crash [@ nsSVGGeometryFrame::HasStroke]

Status: RESOLVED FIXED

(Core :: SVG, defect)

Description

[Jesse Ruderman]

Attachment: testcase (crashes Firefox when loaded)

Thread 0 Crashed:
0   0x00000000 0 + 0
1   nsSVGGeometryFrame::HasStroke() + 153 (nsSVGGeometryFrame.cpp:284)
2   nsSVGPathGeometryFrame::UpdateCoveredRegion() + 93 (nsSVGPathGeometryFrame.cpp:471)
3   nsSVGPathGeometryFrame::UpdateGraphic(int) + 292 (nsSVGPathGeometryFrame.cpp:762)
4   nsSVGPathGeometryFrame::NotifyRedrawUnsuspended() + 55 (nsSVGPathGeometryFrame.cpp:530)
5   nsSVGOuterSVGFrame::UnsuspendRedraw() + 136 (nsSVGOuterSVGFrame.cpp:522)
6   nsSVGOuterSVGFrame::NotifyViewportChange() + 188 (nsSVGOuterSVGFrame.cpp:562)
7   nsSVGSVGElement::InvalidateTransformNotifyFrame() + 142 (nsSVGSVGElement.cpp:1333)
8   nsSVGSVGElement::DidChangeLength(unsigned char, int) + 49 (nsSVGSVGElement.cpp:1443)
...

The top address is often 0x00000000 or 0xdddddddd, but sometimes it's something random-looking.

Comment 1

[Robert Longson [:longsonr]]

Broadly the same cause as bug 386475. When we resolve em units the side effect is to flush layout, in this case that destroys the frame we are processing because there is an unflushed change to layout.

Possible solutions that spring to mind would be one of:

a) Flush before we try to do the outer frame NotifyViewPortChange
b) Rewrite the em units code not to flush.

Comment 2

[Robert Longson [:longsonr]]

The patch in bug 386475 would fix this too.

Comment 3

[Robert Longson [:longsonr]]

Fixed by the check in for bug 386475.

Comment 4

[Jesse Ruderman]

I don't see a crash on branch.  In fact, I get an assertion that indicates that branch doesn't support "em" units in this context.

Comment 5

[Jesse Ruderman]

Crashtest checked in.