Noticed this while debugging a test failure in bug 665815. InvokeArgsGuard() explicitly invokes the default constructor for CallArgsList(), but there is no such constructor and the members of CallArgsList() (such as active_) are uninitialized until the Invoke() happens.
That is weird; I'll tidy up. Btw, InvokeArgsGuard itself is initialized such that InvokeArgsGuard::pushed() returns false until pushInvokeArgs is called (before Invoke), so I don't think there is any actual bug here, yes? (CallArgsList::active() only has meaning once the element has been pushed on the StackSegment::calls_ list).
As for the weirdness: CallArgsList used to have a default constructor, then that was removed b/c of some 'goto' business in JSOP_CALL (which itself was removed b/c LLVM didn't like it...), but this little bit of code was forgotten. Thanks for pointing it out.
Also as a TODO here that Brian pointed out: the two Invoke overloads can be lead to subtle mistakes so perhaps the CallArgs-taking one which is (1) rare and (2) can be wrong should be renamed. Case and point, I think InvokeConstructor calls the wrong overload since it takes an CallArgs&! (This bug would manifest itself as native constructor calls not showing up in the debugger's call stack.)
Created attachment 550775 [details] [diff] [review]
The fix here is to change Invoke to InvokeKernel in the naming style of EvalKernel: if you call this, you should know what you are doing. Also, I fixed some long-standing strangeness in naming re: ExternalInvoke. The "external" "internal" distinction is pretty weak and all ExternalInvoke really does is copy args to the stack for you, regardless of where the call came from. This patch also fixes a real (jsdbgv2-facing) bug, as tested by the addition to testStackIter.js.
Comment on attachment 550775 [details] [diff] [review]
Review of attachment 550775 [details] [diff] [review]:
@@ +813,5 @@
> +InvokeConstructor(JSContext *cx, const Value &fval, uintN argc, Value *argv,
> + Value *rval)
@@ +134,1 @@
Kill the braces.
@@ +1387,2 @@
> *vp = rval;
> return ok;
Might as well eliminate the rval middleman here, right?