SpiderMonkey: How to evaluate local variables by name from callback?
Henry Pasternack
I would like to implement a simple trace() callback function. When invoked,
it would print to the console the values of selected local variables.
Here's a simplified version of what I thought would work. I find it resolves
global variables, but not local function variables or arguments. Oddly enough,
I swear the code was working briefly this morning. JS_EvaluateInStackFrame()
returns false and the interpreter complains that "a" is undefined. I can see that
fp->vars and fp->nvars look reasonable.
(SpiderMonkey callback for "Trace":)
JSBool doTrace(JSContext *cx, JSObject *obj, uintN argc, jsval *argv, jsval *rval)
{
JSStackFrame *fp = cx->fp->down;
char *traceScript = "a";
jsval val;
if (JS_EvaluateInStackFrame(cx, fp, traceScript, strlen(traceScript), 0, 0, &val)) {
printf("%s\n", JS_ValueToString(cx, val));
}
return JS_TRUE;
}
(JavaScript:)
function foo() {
var a = 999
Trace()
}
foo()
If this isn't a good approach, can anyone suggest a better one? Thanks very much.
-Henry
Brendan Eich
> If this isn't a good approach, can anyone suggest a better one? Thanks very much.
What version of SpiderMonkey are you using? You might try the
cvs-mirror.mozilla.org trunk if you haven't yet.
/be
Henry Pasternack
> What version of SpiderMonkey are you using? You might try the cvs-mirror.mozilla.org trunk if you haven't yet.
Hmm. I built it from js-1.5.tar.gz. Is there a known issue here?
Thanks.
-Henry
Henry Pasternack
> Hmm. I built it from js-1.5.tar.gz. Is there a known issue here?
Sorry -- I should be more proactive. I'll have a whack at installing
CVS and see if the problem persists with the latest sources.
Thanks.
-Henry
Henry Pasternack
> Sorry -- I should be more proactive. I'll have a whack at installing
> CVS and see if the problem persists with the latest sources.
I pulled down the latest sources and built on Fedora Core 4. (I had
been working on Windows XP). The results are the same. The call to
JS_EvaluateInStackFrame() succeeds when the trace script refers to a
variable name declared in global scope, but fails if it refers to a
local parameter or variable.
I'm a bit bewildered because, as I said, it seemed to be working for
a brief time yesterday. Since I have no formal docs on the debug API,
it would be helpful to know if the general approach is correct. If
so, and if you have the time, I could post my test program. Perhaps
I am missing a detail or two.
Thanks.
-Henry
John Bandhauer
to make assumptions about when the engine will or won't make a stack
frame. And, walking cx->fp->down is not as 'safe' as using
JS_FrameIterator (which is in the public engine API). I can't say if
Brendan was hinting at any known problem in any specific version of the
engine. But, at times in the past I know that aggressive optimization in
the engine would sometimes 'hide' otherwise unused or locally used
variables from debugging code. I don't know if this has recently been a
problem.
It might be useful for you to look at or simply *use* some code for this
sort of thing that I wrote 6(!) years ago. It is in the cvs tree in the
xpconnect sources. But, I believe it makes straightforward use of the
JSAPI and has no real dependencies on xpconnect. You can get it from
mozilla cvs and browse it at:
http://lxr.mozilla.org/seamonkey/source/js/src/xpconnect/src/xpcdebug.cpp
Mainly it lets you just insert the 'debugger;' keyword in your code (in
place of your Trace() function) and dumps a detailed stack trace with
variables and function params.
I have not run that code for a long time. But, I would say that if you
find it to not work then that would be a good reason to file bugs
against the JS engine.
There is a document about this at:
http://www.mozilla.org/scriptable/javascript-stack-dumper.html
Hope this helps,
John.
Brendan Eich
> No showstopper in your code jumps out at me. FWIW, it is not really safe
> to make assumptions about when the engine will or won't make a stack
> frame. And, walking cx->fp->down is not as 'safe' as using
> JS_FrameIterator (which is in the public engine API). I can't say if
> Brendan was hinting at any known problem in any specific version of the
> engine. But, at times in the past I know that aggressive optimization in
> the engine would sometimes 'hide' otherwise unused or locally used
> variables from debugging code. I don't know if this has recently been a
> problem.
I thought there was, but if so, it's still there. Indeed, I see no
js_GetCallObject call in or under JS_EvaluateUCInStackFrame. Suggest
Henry use JS_FrameIterator as you wrote, and call JS_GetFrameCallObject
before calling JS_EvaluateUCInStackFrame. That should work around the
bug in this Evaluate API.
/be
Henry Pasternack
results.
-Henry
"Brendan Eich" <bre...@meer.net> wrote in message news:44248D5A...@meer.net...
Henry Pasternack
>calling JS_EvaluateUCInStackFrame.
That did the trick. I appreciate the assistance.
-Henry