914286 - [jsdbg2] evalInFrame frames should have next-youngest frame as their 'older', not necessarily their scope frame

Status: NEW

(Core :: JavaScript Engine, defect, P3)

Description

[Jim Blandy :jimb]

Debugger.Frame.prototype.eval can evaluate code in the scope of any live frame F, not just in the scope of the youngest frame. However, the frame created by F.eval(...) currently reports F as its 'older', even if F is not the youngest frame.

This is incorrect: .older should reflect the debuggee's current continuation; the frame in whose scope we're evaluating code is the static link, not the dynamic link.

Here's a test case:

var g = newGlobal();
g.eval('function f1(x) { f2(x+1); }');
g.eval('function f2(y) { debugger; }');

var dbg = new Debugger(g);



Debugger.Frame.prototype.toString = function () {
  if (this.callee && this.callee.displayName)
    var callee = this.callee.displayName + " at ";
  else
    var callee = '';

  return "[" + this.type + " " + callee + uneval(this.url) + ":" + this.script.getOffsetLine(this.offset) + "]";
}

dbg.onDebuggerStatement = function (frame) {
  dbg.onDebuggerStatement = function (frame) {
    dbg.onDebuggerStatement = function (frame) {
      print("Whoa!");
    }

    print("inner 0: " + frame);
    print("inner 1: " + frame.older);
    print("inner 2: " + frame.older.older);
  }

  frame.older.eval("debugger;");
}

g.f1(0);


This should print:

inner 0: [eval (void 0):1]
inner 1: [call f2 at (void 0):3]
inner 2: [call f1 at (void 0):2]


But it actually prints:

inner 0: [eval (void 0):1]
inner 1: [call f1 at (void 0):2]
inner 2: null

Comment 1

[Jim Blandy :jimb]

(In reply to Jan de Mooij [:jandem] from comment #18)
> So if the stack looks like this, old to new:
> 
> - frame 1
> - frame 2
> - frame 3
> 
> And we perform an evalInFrame("print(Error().stack)") in frame 2, it should
> print frames 1-3?

Yes, I think that's the consensus. I suspect that the current behavior is expected by the unit tests, but those should be changed.

> When I refactored a lot of vm/Stack I kept the current behavior (hide frame
> 3), but if we decide we don't need evalInFramePrev that could simplify
> ScriptFrameIter quite a bit and makes it easier to baseline-compile debugger
> frames...

That sounds wonderful, then.

Comment 2

[Jason Orendorff [:jorendorff]]

(In reply to Jan de Mooij [:jandem] from bug 847405 comment #18)
> So if the stack looks like this, old to new:
> 
> - frame 1
> - frame 2
> - frame 3
> 
> And we perform an evalInFrame("print(Error().stack)") in frame 2, it should
> print frames 1-3?

Yes. If it shows frames 1 and 2, it should definitely show frame 3. The stack at that point is:

    frame 1
    frame 2
    frame 3
    one or more frames of debugger code
    the evalInFrame frame

In the browser, there are UI and security concerns. Probably Error().stack should show just the evalInFrame frame and nothing else at all; and the debugger should show frames 1-3 and the evalInFrame frame, but not debugger frames.

In the shell, where there are no security considerations, I think we should see all those frames. Currently we drop frame 3 and the debugger frames--a bug.

Here's a test case for Error().stack, to go with the one in comment0 testing the frame.older chain.

----

var dbg = new Debugger;
var g = newGlobal();
g.eval(
    'function frame1() { frame2(); }\n' +
    'function frame2() { frame3(); }\n' +
    'function frame3() { debugger; }\n');

gw = dbg.addDebuggee(g);
dbg.onDebuggerStatement = function (frame) {
    frame.older.eval("print(Error().stack)");
};

g.frame1();