Author:halw

Date:2009-01-18T20:55:09.000000Z


git-svn-id: https://svn.eiffel.com/eiffel-org/trunk@164 abb3cda0-5349-4a8f-a601-0c33ac3a8c38
This commit is contained in:
halw
2009-01-18 20:55:09 +00:00
parent 3d675b2956
commit 003b100cb9
5 changed files with 35 additions and 18 deletions

View File

@@ -4,28 +4,29 @@
[[Image:call-stack-tool]]
The call stack tool gives information about the current call stack of a debugged application.
The call stack tool provides information, at a particular point during system execution, about the call stack of a system being executed under control of the debugger.
It is mainly composed of a list representing the call stack elements, where the entry feature of the program is at the bottom and the top of the call stack is at the top. <br/>
- The current call stack element, to which the [[Information relative to a stack element|other debug tools]] refer, is represented by a green arrow [[Image:callstack-active-arrow-icon]] . <br/>
- Clicking on a call stack element represented by an empty arrow [[Image:callstack-empty-arrow-icon]] , or picking it and dropping it onto either the call stack list or the locals view defines it as being the current call stack element. <br/>
- The call stack elements with no pixmap are called external call stack elements, they represent a call stack out of Eiffel, for instance a true dotnet call stack. <br/>
- For each feature in the call stack, its name, its dynamic class and its static class are displayed. An asterisk next to the name of a feature means the feature is melted, as opposed to frozen. The dynamic class is the type of the object upon which the feature is called, whereas the static class is the class in which the feature was written.
The call stack is composed of a list representing the call stack elements, in which the root procedure of the system is at the bottom of the list and the currently executing routine is at the top. <br/>
* The currently selected call stack element, to which the [[Information relative to a stack element|other debugger tools]] refer, is indicated by a green arrow [[Image:callstack-active-arrow-icon]] . <br/>
* Clicking on a call stack element represented by an empty arrow [[Image:callstack-empty-arrow-icon]] , or picking the element and dropping it onto either the call stack list or the locals view defines it as being the currently selected call stack element. <br/>
* The call stack elements with no icon are called external call stack elements, they represent a call stack out of Eiffel, for example, a true .NET call stack. <br/>
* For each feature in the call stack, the name, dynamic class, and static class are displayed. The dynamic class is the type of the object upon which the feature is called, whereas the static class is the class in which the feature was written.
* An asterisk next to the name of a feature means the feature is melted, as opposed to frozen.
On top of this list, a line gives the state of the debugged application, and another one describes the exception that caused the application to stop, if any. For more information concerning exceptions, see the [[Supported exceptions|supported exceptions]] .
The button [[Image:debug-exception-dialog-icon]] is used to open the Exception dialog which show the exception details. For instance a call on Void target in a dotnet system would popup :
At the top of the list, one line of text gives the state of the debugged application, in this case "Status = Breakpoint reached". A second line describes the exception that caused the application to stop, if any. In the case shown above, execution stopped at a breakpoint, so no exception is shown on the second line. For more information concerning exceptions, see the [[Supported exceptions|supported exceptions]].
The button [[Image:debug-exception-dialog-icon]] is used to open the Exception dialog which show the exception details. For instance a call on Void target in a .NET system would popup :
[[Image:exception-dialog]]
When more than one thread is available to the debugger, you can switch from one to the other, for that you have to click on the thread's id "0x000..." and select from the popup list of available threads. Or (recommended) you can use the [[Threads tool|threads tool]] (clicking on '''Show threads panel''' will show the threads tool).
When more than one thread is available to the debugger, you can switch from one thread to another. To do that, click on the thread's id "0x000..." and select from the pop-up list of available threads. Or (recommended) you can use the [[Threads tool|threads tool]] (clicking on '''Show threads panel''' will show the threads tool).
[[Image:call-stack-tool-with-threads]]
In the toolbar, the button [[Image:general-save-icon]] gives the possibility to [[Save call stack|save the call stack]] to a text file, and the button [[Image:general-copy-icon]] copy to the clipboard. The [[Image:debugger-callstack-depth-icon]] button makes it possible to choose which call stack depth should be displayed in the list (the default is to display the 100 top stack elements, but it is configurable with the same button).
In the toolbar, the button [[Image:general-save-icon]] gives you the capability to [[Save call stack|save the call stack]] to a text file. The button [[Image:general-copy-icon]] can be used to copy the call stack to the clipboard. The [[Image:debugger-callstack-depth-icon]] button makes it possible to choose a desired depth for the call stack in the list (the default is to display the 100 top stack elements).

View File

@@ -1,11 +1,11 @@
[[Property:title|Information relative to a stack element]]
[[Property:weight|2]]
[[Property:uuid|f78fca33-2e19-1021-70f4-fd262991da7a]]
In addition to the [[Call stack tool: Interface|call stack tool]] that provides information concerning the call stack in its globality, some other debug tools give information concerning the [[Call stack tool: Interface|current call stack element]] .
In addition to the [[Call stack tool: Interface|call stack tool]] that provides global information concerning the call stack, some other debug tools give more detailed information concerning the [[Call stack tool: Interface|currently selected call stack element]] .
In debug mode, the context tool is automatically switched to the feature tab in flat view, and displays the feature which corresponds to the current call stack element. In the left margin, a yellow arrow ( [[Image:bp-current-line-icon]] ) marks the execution line where the program is currently stopped, whereas a green arrow ( [[Image:bp-slot-other-frame-icon]] ) indicates the execution line that was attained in the feature in the current call stack element. Therefore, if a feature is recursive, and appears several times in the call stack, changing the current call stack element may cause green arrows to be displayed at different places in the same feature (if the different calls did not reach the same execution point). On the other hand, the yellow arrow can only appear at one place as long as the application is not started again.
The left part of the [[Objects tool: Introduction|object tool]] gives valuable information concerning parameters that were passed to the feature corresponding to the current call stack, the current value of the local variables, and, if it is a function, the current value of its result.
The left part of the [[Objects tool: Introduction|object tool]] gives valuable information concerning parameters that were passed to the feature corresponding to the current call stack, the current value of the local variables, and, if the feature is a function, the current value of its result.

View File

@@ -1,7 +1,7 @@
[[Property:title|Save call stack]]
[[Property:weight|4]]
[[Property:uuid|495a2601-8e25-0b48-f86a-6cccf7099c1e]]
It is possible to copy the current call stack to the clipboard ( [[Image:general-copy-icon]] ) or to a text file ( [[Image:general-save-icon]] ). This may be useful to indicate to other people of a team where an error occurred. After the button is clicked, a dialog is popped up that prompts for a place where to save the [[Call stack tool: Interface|call stack]] (if the selected file already exists, it is overwritten).
It is possible to copy the current call stack to the clipboard ( [[Image:general-copy-icon]] ) or to a text file ( [[Image:general-save-icon]] ). This may be useful to indicate to other members of a team where an error has occurred. After the button is clicked, a dialog is popped up that prompts for a place in which to save the [[Call stack tool: Interface|call stack]] file (if the selected file already exists, it is overwritten).

View File

@@ -1,10 +1,26 @@
[[Property:title|Execution record and replay]]
[[Property:weight|-12]]
[[Property:uuid|5184f354-f954-49e2-d38f-15214dcd3d6b]]
* [[Introduction to execution record and replay|Introduction]]
* [[Record execution|Execution recording]]
* [[Replay (recorded) execution|Execution replaying]]
This feature allows you to record the debugger controlled execution of your system, and then replay this recording when the debugger is stopped. One could regard this feature as a rewind/forward, or undo/redo of the execution calls.<br/>
In practice,
* the debugger is [[Record execution|recording]] the effective routine calls, and the attribute assignments, as well as the local variable assignments.
* when the execution is stopped, you can [[Replay (recorded) execution|replay]] the previous execution from its recording.
* when [[Replay (recorded) execution|replaying]] a recorded execution, the debugger restores the recorded values, and changes the execution cursor to show the recorded context (values, calls) in the debugging tool.
* This way you can use the standard debugging tools to view, inspect the values, browse the calls, and even evaluate expressions on objects ( but, be careful, if you evaluate expressions to avoid side effects).
The execution record and replay functionalities are graphically available on the Call stack tool, or though the "Execution" menu (formerly the "Debug" menu).
How to use it
* Execute while [[Record execution|recording]]
* [[Replay (recorded) execution|Replay]] and use the debugging tools to browse, inspect, evaluate, ...
{{caution|There is a '''specific limitation''' that '''once''' routine's information (not yet called ...) are not recorded and thus not restored as one might expect (for instance, the debugger does not reset a once during replay). This may be changed in a later release.}}
{{caution|Be aware that there is a logical '''limitation''' concerning the world external to EiffelStudio. That is, it is not possible for EiffelStudio to record and replay external changes such as file or database modifications.<br/>
Likewise if, during an external routine call, some Eiffel values are changed, those are not recorded (and thus not replayed).}}
{{note|EiffelStudio provides record and replay '''only in classic mode'''. So the facility is not yet supported for .NET systems.}}