Debugger: Difference between revisions

484 bytes added ,  4 March 2011
m
→‎Debug.Frame: formatting; clarifications.
(→‎Debug.Frame: First cut.)
m (→‎Debug.Frame: formatting; clarifications.)
Line 105: Line 105:
==Debug.Frame==
==Debug.Frame==


A <code>Debug.Frame</code> instance represents a debuggee stack frame. It provides operations for finding the script the frame is executing, the frame that invoked it, and the lexical scope in which the execution is taking place.
A <code>Debug.Frame</code> instance represents a debuggee stack frame. Given a <code>Debug.Frame</code> instance, you can find the script the frame is executing, walk the stack to older frames, find the lexical environment in which the execution is taking place, and so on.


A <code>Debug.Frame</code> instance is a weak reference to the frame; once the debuggee destroys the frame (perhaps by returning from a function or completing an <code>eval</code> call), further operations on the <code>Debug.Frame</code> instance will raise an error.
SpiderMonkey creates instances of <code>Debug.Frame</code> as needed in two situations: when it calls a hook function that expects a frame as an argument, and when the debugger reads an existing frame's <code>older</code> property. SpiderMonkey creates only one <code>Debug.Frame</code> instance for a given debuggee frame; every hook function called while the debuggee is running in a given frame receives the same frame object; and walking the stack back to a previously accessed frame yields the same frame object as before. Debugger code can add its own properties to a frame object and expect to find them later, use <code>==</code> to decide whether two expressions refer to the same frame, and so on.


SpiderMonkey creates instances of <code>Debug.Frame</code> as needed in two situations: when calling a hook function that expects a frame as an argument; and when an existing frame's <code>older</code> property is accessed. SpiderMonkey creates only one <code>Debug.Frame</code> instance for a given debuggee frame; every hook function called while the debuggee is running in a given frame receives the same frame object. Thus, debugger code can place its own properties on a frame object and expect to find them later, use <code>==</code> to decide whether two expressions refer to the same frame, and so on.
A <code>Debug.Frame</code> instance is a weak reference to the frame; once the debuggee destroys the frame (perhaps by returning from the function or completing the <code>eval</code> call), the <code>Debug.Frame</code> instance becomes inactive: its properties become undefined, and calls to its methods will throw an exception.


A <code>Debug.Frame</code> instance has the following properties, which are all non-writable and non-configurable:
A <code>Debug.Frame</code> instance has the following properties, which are all non-writable and non-configurable:
Line 117: Line 117:
<dd>A string describing what sort of frame this is:
<dd>A string describing what sort of frame this is:
<ul>
<ul>
<li><code>"call"</code>: a frame running a function that was called.
<li><code>"call"</code>: a frame running a function call.
<li><code>"eval"</code>: a frame running code passed to <code>eval</code>.
<li><code>"eval"</code>: a frame running code passed to <code>eval</code>.
<li><code>"global"</code>: a frame running global code (JavaScript that is neither of the above)
<li><code>"global"</code>: a frame running global code (JavaScript that is neither of the above)
Line 124: Line 124:
<li><code>"dummy"</code>: a frame pushed for stupid people (rather&mdash;I don't know what this is)
<li><code>"dummy"</code>: a frame pushed for stupid people (rather&mdash;I don't know what this is)
</ul>
</ul>
</dl>


(Note that a <code>"debugger"</code> frame represents the debugger continuation expecting the expression's value; the expression itself has its own <code>"eval"</code> frame.)
(Note that a <code>"debugger"</code> frame represents the debugger continuation expecting the expression's value; the expression itself has its own <code>"eval"</code> frame.)
Line 164: Line 163:
<dt>eval(<i>code</i>)
<dt>eval(<i>code</i>)
<dd>Begin evaluating <i>code</i> in the scope of this frame. <i>Code</i> is a string. This pushes a <code>"debugger"</code> frame on the debuggee's stack, evaluates <i>code</i> with all extant hook functions active, and returns a value of the sort passed to an <code>enterFrame</code> completion function describing how the code completed.
<dd>Begin evaluating <i>code</i> in the scope of this frame. <i>Code</i> is a string. This pushes a <code>"debugger"</code> frame on the debuggee's stack, evaluates <i>code</i> with all extant hook functions active, and returns a value of the sort passed to an <code>enterFrame</code> completion function describing how the code completed.
Note that, although this method mixes the debugger's own stack frames with the debuggee's, walking the stack only shows the debuggee's frames; the continuation of the debugger's call to this method, up to the debugging hook function call, is represented by a single <code>"debugger"</code> frame.


<dt>finish(<i>result</i>) <i>(future plan)</i>
<dt>finish(<i>result</i>) <i>(future plan)</i>
Confirmed users
497

edits