Closed Bug 726582 Opened 13 years ago Closed 13 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.
Status: NEW → RESOLVED
Closed: 13 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: