I noticed many uninitialied value usage warnings from the execution of
TB under valgrind (memcheck).

Many such usages, today, are related to JavaScript interpreter.  memcheck
can print the stack trace when this condition is noticed.  However,
we only get the traceback of the javascript interpreter itself in this
case.  This is not very useful.

We need to know which javascript file generated the
uninitialized value usage to figure out the problem and fix it.
That is, we need to find out the Context within JavaScript itself.

I wonder if there is a routine, within JS interpreter, that can print out,
at least, the filename of the JavaScript code, and
preferably the additional line number of the JavaScript which JS interpreter is
executing ?
(I have no idea if byte code interpreter or whatever
leaves the line number information in the executable binary blob. That will be 
useful.
Or if such a dumping routine can print out the several byte codes sequence
that leads to the problem [oh well, do we use native compilation these
days? If so, just a few instructions may not be enlightening enough. However,
that I got the stack trace of JavaScript interpreter routines suggest that
it is not 100% native compilation.],
even a crude line number, that gets generated every 5 lines or so, information 
will be useful
if the detailed line number may be considered to bloat the executable blob, 
etc.)

A function with features mentioned above would be very helpful in eliminating 
the
usage of uninitialized variable and bugs.
Of course, additionally, I need to figure out how to tell memcheck to
call such a routine for additional debugging information when non
initialized memory is used. That would be doable one way or the
other. (We may need to hack the memcheck source code, oh well.)

In any case, the number of uninitialized value usages seemed to have
increased in the last several weeks, and they come mainly from
JavaScript, after removal of usages in external library.  This
suggests that there are more JS codes with the uninitialized value
usage problems, or that the program flow has changed somehow due to
internal changes and thus exposed the issues more prominently.

Below are some lines from memcheck session log of running TB under it.

The number of such usages recorded in one session log is

     68    Memcheck:Cond

Close to 60 of them are related to JavaScript interpreter.
This seems bad.

I see more direct number conversion problems (ToNumber(), and
CompartmentChecker() issues today. These are more pronouncd in today's
code than, say, a couple of month ago.)

==7839== Conditional jump or move depends on uninitialised value(s)
==7839==    at 0xB5AA36F: JS::Value::setNumber(double) (FloatingPoint.h:237)
==7839==    by 0xB624F8F: js::DivOperation(JSContext*, JS::Handle<JSScript*>, 
unsigned char*, JS::Handle<JS::Value>,
JS::Handle<JS::Value>, JS::Value*) (jsinterpinlines.h:630)
==7839==    by 0xB63363A: js::Interpret(JSContext*, js::StackFrame*, 
js::InterpMode) (jsinterp.cpp:2032)


==7839== Conditional jump or move depends on uninitialised value(s)
==7839==    at 0xB5AA37D: JS::Value::setNumber(double) (jsval.h:351)
==7839==    by 0xB624F8F: js::DivOperation(JSContext*, JS::Handle<JSScript*>, 
unsigned char*, JS::Handle<JS::Value>,
JS::Handle<JS::Value>, JS::Value*) (jsinterpinlines.h:630)
==7839==    by 0xB63363A: js::Interpret(JSContext*, js::StackFrame*, 
js::InterpMode) (jsinterp.cpp:2032)

==7839== Conditional jump or move depends on uninitialised value(s)
==7839==    at 0xB624FB5: js::DivOperation(JSContext*, JS::Handle<JSScript*>, 
unsigned char*, JS::Handle<JS::Value>,
JS::Handle<JS::Value>, JS::Value*) (jsinterpinlines.h:632)
==7839==    by 0xB63363A: js::Interpret(JSContext*, js::StackFrame*, 
js::InterpMode) (jsinterp.cpp:2032)


==7839== Conditional jump or move depends on uninitialised value(s)
==7839==    at 0xB5424B9: js::CompartmentChecker::check(JS::Value const&) 
(jscntxtinlines.h:241)
==7839==    by 0xB62D8E3: void 
js::assertSameCompartmentDebugOnly<JS::Value>(JSContext*, JS::Value const&)
(jscntxtinlines.h:311)
==7839==    by 0xB632210: js::Interpret(JSContext*, js::StackFrame*, 
js::InterpMode) (jsinterp.cpp:2754)
==7839==    by 0xB6380C8: js::RunScript(JSContext*, JS::Handle<JSScript*>, 
js::StackFrame*) (jsinterp.cpp:348)

==7839== Conditional jump or move depends on uninitialised value(s)
==7839==    at 0xB633C84: js::Interpret(JSContext*, js::StackFrame*, 
js::InterpMode) (jsinterpinlines.h:967)
==7839==    by 0xB6380C8: js::RunScript(JSContext*, JS::Handle<JSScript*>, 
js::StackFrame*) (jsinterp.cpp:348)
==7839==    by 0xB638EEB: js::InvokeKernel(JSContext*, JS::CallArgs, 
js::MaybeConstruct) (jsinterp.cpp:406)
==7839==    by 0xB639883: js::Invoke(JSContext*, JS::Value const&, JS::Value 
const&, unsigned int, JS::Value*,
JS::Value*) (jsinterp.h:112)
==7839==    by 0xB5505BB: JS_CallFunctionValue(JSContext*, JSObject*, 
JS::Value, unsigned int, JS::Value*, JS::Value*)
(jsapi.cpp:5802)

==7839== Conditional jump or move depends on uninitialised value(s)
==7839==    at 0xB625785: js::ToPrimitive(JSContext*, JSType, JS::Value*) 
(jsobjinlines.h:1307)
==7839==    by 0xB633C9E: js::Interpret(JSContext*, js::StackFrame*, 
js::InterpMode) (jsinterpinlines.h:967)
==7839==    by 0xB6380C8: js::RunScript(JSContext*, JS::Handle<JSScript*>, 
js::StackFrame*) (jsinterp.cpp:348)
==7839==    by 0xB638EEB: js::InvokeKernel(JSContext*, JS::CallArgs, 
js::MaybeConstruct) (jsinterp.cpp:406)

==7839== Conditional jump or move depends on uninitialised value(s)
==7839==    at 0xB5424B9: js::CompartmentChecker::check(JS::Value const&) 
(jscntxtinlines.h:241)
==7839==    by 0xB556A99: JS::AssertArgumentsAreSane(JSContext*, JS::Value 
const&) (jscntxtinlines.h:302)
==7839==    by 0xAC2D8EF: JS::ToNumber(JSContext*, JS::Value const&, double*) 
(jsapi.h:2742)
==7839==    by 0xB634DA9: js::Interpret(JSContext*, js::StackFrame*, 
js::InterpMode) (jsinterpinlines.h:967)
==7839==    by 0xB6380C8: js::RunScript(JSContext*, JS::Handle<JSScript*>, 
js::StackFrame*) (jsinterp.cpp:348)

==7839== Conditional jump or move depends on uninitialised value(s)
==7839==    at 0x959F5AB: JS::Value::toNumber() const (jsval.h:380)
==7839==    by 0xAC2D99E: JS::ToNumber(JSContext*, JS::Value const&, double*) 
(jsapi.h:2749)
==7839==    by 0xB634DA9: js::Interpret(JSContext*, js::StackFrame*, 
js::InterpMode) (jsinterpinlines.h:967)
==7839==    by 0xB6380C8: js::RunScript(JSContext*, JS::Handle<JSScript*>, 
js::StackFrame*) (jsinterp.cpp:348)

==21147== Conditional jump or move depends on uninitialised value(s)
==21147==    at 0xB5424BE: js::CompartmentChecker::check(JS::Value const&) 
(jscntxtinlines.h:243)
==21147==    by 0xB62B587: void 
js::assertSameCompartment<JS::MutableHandle<JS::Value> >(JSContext*,
JS::MutableHandle<JS::Value> const&) (jscntxtinlines.h:302)
==21147==    by 0xB62B620: js::CallJSNative(JSContext*, int (*)(JSContext*, 
unsigned int, JS::Value*), JS::CallArgs
const&) (jscntxtinlines.h:375)

Above are just random samples.

TIA


_______________________________________________
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Reply via email to