Closed Bug 658499 Opened 13 years ago Closed 10 years ago

Uninitialised value use in _cairo_gstate_stroke

Categories

(Core :: SVG, defect)

x86_64
Linux
defect
Not set
normal

Tracking

()

RESOLVED FIXED
mozilla28

People

(Reporter: jseward, Assigned: jwatt)

References

Details

(Keywords: valgrind, Whiteboard: [qa-])

This is mozilla-aurora, 19 May 2011.
STR= layout/svg/crashtests/483439-1.svg

Adding a printf of gstate->stroke_style.line_width at
cairo-gstate.c:1069 shows the offending value is an infinity, which
doesn't sound like a good line_width to me.

Conditional jump or move depends on uninitialised value(s)
   at 0x65AD2BA: _cairo_gstate_stroke (gfx/cairo/cairo/src/cairo-gstate.c:1069)
   by 0x659E95C: _moz_cairo_stroke_preserve (gfx/cairo/cairo/src/cairo.c:2295)
   by 0x5E80C30: nsSVGGlyphFrame::PaintSVG(nsSVGRenderState*, nsIntRect const*) (layout/svg/base/src/nsSVGGlyphFrame.cpp:406)
   by 0x5E929E8: nsSVGUtils::PaintFrameWithEffects(nsSVGRenderState*, nsIntRect const*, nsIFrame*) (layout/svg/base/src/nsSVGUtils.cpp:1022)
   by 0x5E7365D: nsSVGDisplayContainerFrame::PaintSVG(nsSVGRenderState*, nsIntRect const*) (layout/svg/base/src/nsSVGContainerFrame.cpp:173)
   by 0x5E929E8: nsSVGUtils::PaintFrameWithEffects(nsSVGRenderState*, nsIntRect const*, nsIFrame*) (layout/svg/base/src/nsSVGUtils.cpp:1022)
   by 0x5E7365D: nsSVGDisplayContainerFrame::PaintSVG(nsSVGRenderState*, nsIntRect const*) (layout/svg/base/src/nsSVGContainerFrame.cpp:173)
   by 0x5E84396: nsSVGInnerSVGFrame::PaintSVG(nsSVGRenderState*, nsIntRect const*) (layout/svg/base/src/nsSVGInnerSVGFrame.cpp:112)
   by 0x5E929E8: nsSVGUtils::PaintFrameWithEffects(nsSVGRenderState*, nsIntRect const*, nsIFrame*) (layout/svg/base/src/nsSVGUtils.cpp:1022)
   by 0x5E7365D: nsSVGDisplayContainerFrame::PaintSVG(nsSVGRenderState*, nsIntRect const*) (layout/svg/base/src/nsSVGContainerFrame.cpp:173)
   by 0x5E929E8: nsSVGUtils::PaintFrameWithEffects(nsSVGRenderState*, nsIntRect const*, nsIFrame*) (layout/svg/base/src/nsSVGUtils.cpp:1022)
   by 0x5E87B2B: nsSVGOuterSVGFrame::Paint(nsDisplayListBuilder const*, nsIRenderingContext&, nsRect const&, nsPoint) (layout/svg/base/src/nsSVGOuterSVGFrame.cpp:579)

 Uninitialised value was created by a stack allocation
   at 0x5E80A5F: nsSVGGlyphFrame::PaintSVG(nsSVGRenderState*, nsIntRect const*) (layout/svg/base/src/nsSVGGlyphFrame.cpp:345)
Component: Layout → SVG
QA Contact: layout → general
Version: Other Branch → Trunk
Version: Trunk → Other Branch
Just to save others the trouble of looking this up...
>    by 0x5E80C30: nsSVGGlyphFrame::PaintSVG(nsSVGRenderState*, nsIntRect
> const*) (layout/svg/base/src/nsSVGGlyphFrame.cpp:406)

this points to the last line here:
  402     iter.Reset();
  403 
  404     gfx->NewPath();
  405     AddCharactersToPath(&iter, gfx);
  406     gfx->Stroke();

...and...
>  Uninitialised value was created by a stack allocation
>    at 0x5E80A5F: nsSVGGlyphFrame::PaintSVG(nsSVGRenderState*, nsIntRect
> const*) (layout/svg/base/src/nsSVGGlyphFrame.cpp:345)

sadly, this is just the opening brace of that method:
  343 nsSVGGlyphFrame::PaintSVG(nsSVGRenderState *aContext,
  344                           const nsIntRect *aDirtyRect)
  345 {

Perhaps we've got an empty string or something, and so AddCharactersToPath doesn't actually do anything in this case? (leaving our new path uninitialized, or something?)
sewardj, do you know if this affects trunk, too?  The quoted code in my previous comment is the same on trunk vs. aurora.
(In reply to comment #1)

> >  Uninitialised value was created by a stack allocation
> >    at 0x5E80A5F: nsSVGGlyphFrame::PaintSVG(nsSVGRenderState*, nsIntRect
> > const*) (layout/svg/base/src/nsSVGGlyphFrame.cpp:345)
> 
> sadly, this is just the opening brace of that method:
>   343 nsSVGGlyphFrame::PaintSVG(nsSVGRenderState *aContext,
>   344                           const nsIntRect *aDirtyRect)
>   345 {

Sorry, I should have clarified.  What you can interpret this to
mean is "the uninitialised value comes from a stack allocation
in nsSVGGlyphFrame::PaintSVG".
(In reply to comment #2)
> sewardj, do you know if this affects trunk, too? 

Yes, same thing happens on current trunk.
Version: Other Branch → Trunk
cairo-gstate.c:1069 on my trunk build is:

if (gstate->stroke_style.line_width <= 0.0)

Now nsSVGGlyphFrame::PaintSVG calls SetupCairoStroke(gfx) followed by gfx->Stroke() which ends up at the line above.

nsSVGGeometryFrame::SetupCairoStroke(gfx) calls nsSVGGeometryFrame::SetupCairoStroke which calls SetupCairoStrokeGeometry which calls aContext->SetLineWidth(width) (unless the width is <=0 which it appears not to be in this case according to my debugging).

aContext->SetLineWidth(width) eventually ends up in _cairo_gstate_set_line_width which is:

gstate->stroke_style.line_width = width;

So I don't understand where the UMR is coming from. 

Does something different to the above sequence of events happen on Linux?
bug 889736 removed nsSVGGlyphFrame.
Blocks: 889736
Status: NEW → RESOLVED
Closed: 10 years ago
Resolution: --- → FIXED
Assignee: nobody → jwatt
No longer blocks: 889736
Depends on: 889736
Target Milestone: --- → mozilla28
Whiteboard: [qa-]
You need to log in before you can comment on or make changes to this bug.