Seen running Firefox trunk x86_64 build on Mac OS X 10.6 under valgrind: ==97971== Conditional jump or move depends on uninitialised value(s) ==97971== at 0x108C9551F: js::MaybeGC(JSContext*) (jsgc.cpp:2167) ==97971== by 0x108BFD3A3: JS_MaybeGC (jsapi.cpp:2767) ==97971== by 0x107C21546: nsJSContext::ScriptEvaluated(bool) (nsJSEnvironment.cpp:3127) ==97971== by 0x107C20667: nsJSContext::EvaluateStringWithValue(nsAString_internal const&, JSObject*, nsIPrincipal*, char const*, unsigned int, unsigned int, JS::Value*, bool*) (nsJSEnvironment.cpp:1336) ==97971== by 0x107BC0639: nsXBLProtoImplField::InstallField(nsIScriptContext*, JSObject*, nsIPrincipal*, nsIURI*, bool*) const (nsXBLProtoImplField.cpp:151) ==97971== by 0x107BA1139: XBLResolve(JSContext*, JSObject*, jsid, unsigned int, JSObject**) (nsXBLBinding.cpp:199) ==97971== by 0x106FCEF02: CallResolveOp(JSContext*, JSObject*, JSObject*, jsid, unsigned int, JSObject**, JSProperty**, bool*) (jsobj.cpp:5402) ==97971== by 0x106FCF3B4: js::LookupPropertyWithFlags(JSContext*, JSObject*, jsid, unsigned int, JSObject**, JSProperty**) (jsobj.cpp:5455) ==97971== by 0x106FDDB4D: js_SetPropertyHelper(JSContext*, JSObject*, jsid, unsigned int, JS::Value*, int) (jsobj.cpp:6105) ==97971== by 0x106F8F235: js::Interpret(JSContext*, js::StackFrame*, js::InterpMode) (jsinterp.cpp:3743) ==97971== by 0x106FBA3C6: js::RunScript(JSContext*, JSScript*, js::StackFrame*) (jsinterp.cpp:584) ==97971== by 0x106FBB6F8: js::InvokeKernel(JSContext*, js::CallArgs, js::MaybeConstruct) (jsinterp.cpp:647) Will mark as security sensitive to be safe, hopefully it isn't necessary.
Could you take a look at this, Terrence? It looks like gcNumFreeArenas isn't initialized. It should be done in the JSRuntime constructor, which is in jsapi.cpp.
At worst we perform a GC the first time we enter MaybeGC so it's not sec-sensitive.
Assignee: general → terrence
Status: NEW → ASSIGNED
OS: Mac OS X → All
Hardware: x86_64 → All
The pages I loaded under valgrind when this came up: the Mozilla nightly home page, w3.org, and espn.com.
Attachment #576209 - Flags: review?(wmccloskey)
Comment on attachment 576209 [details] [diff] [review] v1: trivial Thanks.
Attachment #576209 - Flags: review?(wmccloskey) → review+
If your sure this is not sec-sensative then please unhide. This appears to be resolved, so I am marking it (resolved->fixed), per request from Ed Morely who monitors mozilla-inbound > mozilla-central merges.
Status: ASSIGNED → RESOLVED
Closed: 8 years ago
Resolution: --- → FIXED
adding the changeset that landed this in m-c : https://hg.mozilla.org/mozilla-central/rev/2c13341cc1c1 and setting target milestone to FF 11
Target Milestone: --- → mozilla11
This is a "regression" from bug 700357 which added this property. Unfortunately that landed the day before the merge and made it into Fx 10, so we need to land this fix on Aurora as well.
Looking at the code I agree w/Gregor in comment 2: the only decision based on this possibly bogus value is whether to GC now or wait a bit and that's not a security problem.
Daniel, thanks for unhiding this: I don't have permission bits to do that. If we want to go ahead and push this to FF10, there is zero risk in doing so.
*sigh* Bugzilla, why do you do these things to me? I can't even see the fields I just unset.
Attachment #576209 - Flags: approval-mozilla-aurora? → approval-mozilla-aurora+
You need to log in before you can comment on or make changes to this bug.