Uninitialised value use in _cairo_gstate_stroke

RESOLVED FIXED in mozilla28

Status

()

Core
SVG
RESOLVED FIXED
7 years ago
4 years ago

People

(Reporter: jseward, Assigned: jwatt)

Tracking

({valgrind})

Trunk
mozilla28
x86_64
Linux
valgrind
Points:
---

Firefox Tracking Flags

(Not tracked)

Details

(Whiteboard: [qa-])

(Reporter)

Description

7 years ago
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.
(Reporter)

Comment 3

7 years ago
(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".
(Reporter)

Comment 4

7 years ago
(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
Last Resolved: 4 years ago
Resolution: --- → FIXED
Assignee: nobody → jwatt
No longer blocks: 889736
Depends on: 889736
Target Milestone: --- → mozilla28

Updated

4 years ago
Whiteboard: [qa-]
You need to log in before you can comment on or make changes to this bug.