519498 - UMR in XPCWrappedNative::CallMethod

Status: RESOLVED FIXED

(Core :: XPConnect, defect)

Description

[Robert Sayre]

looks there's no way this should happen--could be pretty bad.

Comment 1

[Robert Sayre]

Attachment: valgrind stack

Comment 2

[Robert Sayre]

==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==

Comment 3

[Blake Kaplan (:mrbkap) (inactive)]

Attachment: 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 4

[Robert Sayre]

Comment on attachment 403646 [details] [diff] [review]
Fix

NS_ENSURE_SUCCESS?

Comment 5

[Blake Kaplan (:mrbkap) (inactive)]

http://hg.mozilla.org/mozilla-central/rev/cebf1a09f168

Comment 6

[Blake Kaplan (:mrbkap) (inactive)]

http://hg.mozilla.org/releases/mozilla-1.9.2/rev/356efd3ad9af

Comment 7

[Daniel Veditz [:dveditz]]

Comment on attachment 403646 [details] [diff] [review]
Fix

Approved for 1.9.1.5, a=dveditz for release-drivers

Comment 8

[Blake Kaplan (:mrbkap) (inactive)]

http://hg.mozilla.org/releases/mozilla-1.9.1/rev/7d3a8b0689a0