Closed Bug 726582 Opened 12 years ago Closed 12 years ago

Uninitialised value use in nsSMILCSSProperty::ValueFromString

Categories

(Core :: SVG, defect)

defect
Not set
normal

Tracking

()

RESOLVED FIXED
mozilla13

People

(Reporter: jseward, Assigned: jwatt)

Details

Attachments

(1 file)

TEST_PATH=content/smil/test/test_smilCSSFontStretchRelative.xhtml

(DISPLAY=:3.0 make -C ff-opt mochitest-plain TEST_PATH=content/smil/test/test_smilCSSFontStretchRelative.xhtml EXTRA_ST_ARGS='--close-when-done --debugger=/home/sewardj/VgTRUNK/merge/Inst/bin/valgrind --debugger-args="--smc-check=all-non-file --suppressions=/home/sewardj/MOZ/SUPPS/mochitest-mc.supp --error-limit=no --stats=yes --trace-children=yes --child-silent-after-fork=yes '--trace-children-skip=/usr/bin/hg,/bin/rm,*/bin/certutil,*/bin/pk12util,*/bin/ssltunnel,*/bin/uname,*/bin/which,*/bin/ps,*/bin/grep' --tool=memcheck --track-origins=yes --stats=yes"') 2>&1 | cat

Conditional jump or move depends on uninitialised value(s)
   at 0x68DFCA2: nsSMILCSSProperty::ValueFromString(nsAString_internal const&, nsISMILAnimationElement const*, nsSMILValue&, bool&) const (nsSMILCSSProperty.cpp:175)
   by 0x68DDE32: nsSMILAnimationFunction::ParseAttr(nsIAtom*, nsISMILAttr const&, nsSMILValue&, bool&) const (nsSMILAnimationFunction.cpp:760)
   by 0x68DEB0C: nsSMILAnimationFunction::GetValues(nsISMILAttr const&, nsTArray<nsSMILValue, nsTArrayDefaultAllocator>&) (nsSMILAnimationFunction.cpp:815)
   by 0x68DEF30: nsSMILAnimationFunction::ComposeResult(nsISMILAttr const&, nsSMILValue&) (nsSMILAnimationFunction.cpp:243)
   by 0x68DF64A: nsSMILCompositor::ComposeAttribute() (nsSMILCompositor.cpp:124)
   by 0x68DBC58: DoComposeAttribute(nsSMILCompositor*, void*) (nsSMILAnimationController.cpp:380)
   by 0x6D59EE4: PL_DHashTableEnumerate (pldhash.cpp:754)
   by 0x68DCFB5: nsSMILAnimationController::DoSample(bool) (nsTHashtable.h:241)
   by 0x68B9400: nsSVGSVGElement::SetCurrentTime(float) (nsSVGSVGElement.cpp:514)
   by 0x6DA1CB7: NS_InvokeByIndex_P (xptcinvoke_x86_64_unix.cpp:195)
   by 0x69242BA: XPCWrappedNative::CallMethod(XPCCallContext&, XPCWrappedNative::CallMode) (XPCWrappedNative.cpp:2898)
   by 0x692A5CF: XPC_WN_CallMethod(JSContext*, unsigned int, JS::Value*) (XPCWrappedNativeJSOps.cpp:1539)

 Uninitialised value was created by a stack allocation
   at 0x68DDD70: nsSMILAnimationFunction::ParseAttr(nsIAtom*, nsISMILAttr const&, nsSMILValue&, bool&) const (nsSMILAnimationFunction.cpp:755)
Assignee: nobody → jwatt
OS: Linux → All
Hardware: x86_64 → All
Attached patch patchSplinter Review
Fixed a couple of other callers too.
Attachment #596681 - Flags: review?(dholbert)
This variable is an outparam, and IIRC aSMILAttr.ValueFromString should set its value in all of its success clauses.

Julian: does comment 0 indicate that the variable's uninitialized value is actually getting used somewhere, or could this be a false positive?  (i.e. is it just warning to be "on the safe side"?)  I don't know how extensively valgrind checks these things.
Comment on attachment 596681 [details] [diff] [review]
patch

Having said that, I doubt the initialization actually costs us anything, so it's probably worth doing just for extra safety and (if it's a false-positive) to quiet valgrind.

The commit message is a little misleading right now, though.  Could you change it to say "initialize outparam preventCachingOfSandwich before passing it to nsISMILAttr::ValueFromString" or something like that?  (indicating that it's an outparam, not just a normal variable that's being passed in)

r=me with that
Attachment #596681 - Flags: review?(dholbert) → review+
Ah. We should be checking ValueFromString's return-value there, and ignoring preventCachingOfSandwich if ValueFromString failed.

We should definitely do that as well -- that's the "right" fix for this, I think -- but I'd be OK keeping these explicit initializations as an additional protection.
Oh, sorry, I misunderstood what stack level that was at, so my last comment may have been bogus. Re-reading the code.
Yeah, so comment 5 was basically right, though we need to check failure in a different way.  nsSMILCSSValueType::ValueFromString fails by returning a null |aValue| outparam, it looks like.

So we want to add 
  if (aValue.IsNull) {
    return NS_ERROR_FAILURE;
  }

after the nsSMILCSSValueType::ValueFromString() call, I believe. (in the code pointed to by comment 4)

That should fix this.
Pushed https://hg.mozilla.org/integration/mozilla-inbound/rev/a7f0285cde9a

As discussed on IRC with dholbert, I've kept my original changes as well as integrating the fix from comment 7.
(In reply to Daniel Holbert [:dholbert] from comment #2)

> Julian: does comment 0 indicate that the variable's uninitialized value is
> actually getting used somewhere, or could this be a false positive?  (i.e.
> is it just warning to be "on the safe side"?)  I don't know how extensively
> valgrind checks these things.

(I know this is now irrelevant, but ..) yes, you get a warning like this
whenever some uninitialised value is used to make a control flow decision,
in this case to influence what happens at 

  if (!aPreventCachingOfSandwich && mPropID == eCSSProperty_display) {
    aPreventCachingOfSandwich = true;
  }

False positives have been known to occur, but they are rare and getting
rarer as the uninitialised-value analysis mechanism gets refined.
https://hg.mozilla.org/mozilla-central/rev/a7f0285cde9a
Status: NEW → RESOLVED
Closed: 12 years ago
Resolution: --- → FIXED
Target Milestone: --- → mozilla13
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Created:
Updated:
Size: