looks there's no way this should happen--could be pretty bad.
==4856== Conditional jump or move depends on uninitialised value(s) ==4856== at 0x52C5DCA: XPCWrappedNative::CallMethod(XPCCallContext&, XPCWrappedNative::CallMode) (xpcwrappednative.cpp:2583) ==4856== by 0x52CACC1: XPC_WN_CallMethod(JSContext*, JSObject*, unsigned int, long*, long*) (xpcwrappednativejsops.cpp:1590) ==4856== by 0x6565904: js_Invoke (jsinterp.cpp:1386) ==4856== by 0x655558E: js_Interpret (jsinterp.cpp:5179) ==4856== by 0x656441D: js_Execute (jsinterp.cpp:1622) ==4856== by 0x652C9B4: JS_EvaluateUCScriptForPrincipals (jsapi.cpp:5145) ==4856== by 0x652DC0B: JS_EvaluateScriptForPrincipals (jsapi.cpp:5109) ==4856== by 0x403C17: ProcessArgs(JSContext*, JSObject*, char**, int) (xpcshell.cpp:1079) ==4856== by 0x4043C4: main (xpcshell.cpp:1739) ==4856== Uninitialised value was created by a stack allocation ==4856== at 0x5B430E2: nsBinaryInputStream::ReadBoolean(int*) (nsBinaryStream.cpp:474) ==4856==
Created attachment 403646 [details] [diff] [review] Fix This shouldn't actually affect non-valgrind builds since we don't convert the uninitialized memory to a return value and we also don't have to deallocate it.
Comment on attachment 403646 [details] [diff] [review] Fix NS_ENSURE_SUCCESS?
Comment on attachment 403646 [details] [diff] [review] Fix Approved for 18.104.22.168, a=dveditz for release-drivers