Confirmed users
497
edits
Debugger: Difference between revisions
Jump to navigation
Jump to search
Accessing properties of dead objects throws an exception.
(→Function Properties of the Debugger Prototype Object: No, it's a bug.) |
(Accessing properties of dead objects throws an exception.) |
||
| Line 262: | Line 262: | ||
SpiderMonkey creates only one <code>Debugger.Frame</code> instance for a given debuggee frame. Every hook object method called while the debuggee is running in a given frame receives the same frame object. Similarly, walking the stack back to a previously accessed debuggee 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 only one <code>Debugger.Frame</code> instance for a given debuggee frame. Every hook object method called while the debuggee is running in a given frame receives the same frame object. Similarly, walking the stack back to a previously accessed debuggee 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. | ||
When the debuggee pops a stack frame (say, because a function call has returned or an exception has been thrown from it), the <code>Debugger.Frame</code> instance referring to that frame becomes inactive: its <code>live</code> property becomes <code>false</code>, its properties | When the debuggee pops a stack frame (say, because a function call has returned or an exception has been thrown from it), the <code>Debugger.Frame</code> instance referring to that frame becomes inactive: its <code>live</code> property becomes <code>false</code>, and accessing its other properties or calling its methods throws an exception. Note that frames only become inactive at times that are predictable for the debugger: when the debuggee runs, or when the debugger removes frames from the stack itself. | ||
Although the debugger shares a JavaScript stack with the debuggee, the stack frames presented to the debugger via this interface never include the frames running the debugger's own JavaScript code. (Note that <code>"debugger"</code> frames represent continuations that pass control from debuggee code that has completed execution to the debugger, not the debugger's frames themselves.) | Although the debugger shares a JavaScript stack with the debuggee, the stack frames presented to the debugger via this interface never include the frames running the debugger's own JavaScript code. (Note that <code>"debugger"</code> frames represent continuations that pass control from debuggee code that has completed execution to the debugger, not the debugger's frames themselves.) | ||
| Line 406: | Line 406: | ||
<dd>True if the script this <code>Debugger.Script</code> instance refers to still exists in the debuggee; false if it has been destroyed. | <dd>True if the script this <code>Debugger.Script</code> instance refers to still exists in the debuggee; false if it has been destroyed. | ||
For most scripts, this property is always true. However, when a call to <code>eval</code> or a similar feature returns, the script representing the top-level code is deleted. When this occurs, the script's <code>live</code> property becomes false, its properties | For most scripts, this property is always true. However, when a call to <code>eval</code> or a similar feature returns, the script representing the top-level code is deleted. When this occurs, the script's <code>live</code> property becomes false, and accessing its other properties or calling its methods throws an exception. Scripts are only deleted when the debuggee is running; the debugger need not worry that a script will be deleted by garbage collection or some other asynchronous activity. | ||
</dl> | </dl> | ||