created 20.11

git-svn-id: https://svn.eiffel.com/eiffel-org/trunk@2267 abb3cda0-5349-4a8f-a601-0c33ac3a8c38
This commit is contained in:
eifops
2020-12-04 15:34:39 +00:00
parent 0f1156d9cc
commit 5049d0d511
2944 changed files with 62467 additions and 0 deletions

View File

@@ -0,0 +1,34 @@
[[Property:title|Call stack tool: Interface]]
[[Property:weight|1]]
[[Property:uuid|ff70f68f-31db-c5d1-4d68-7b0fc70b1dd7]]
[[Image:call-stack-tool]]
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.
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.
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 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 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

@@ -0,0 +1,14 @@
[[Property:title|Call stack tool]]
[[Property:weight|-13]]
[[Property:uuid|8c3cd0fe-78aa-7ec6-f36a-2233a4e26755]]
The call stack is the list of routines that have been entered during execution, but not yet exited since execution started. The list can be considered a '''stack''' structure, because before any routine, say <code>my_routine</code>, can exit, any routine that <code>my_routine</code> may have called must have exited first. Therefore the last entered feature is listed at the top of the stack and the program root feature is its bottom.
There is one level in the call stack, the currently selected element, that has a special status. It is the level to which all debugging tools refer. The currently selected element is, as you might guess, user-selectable. So it is possible to move along the call stack, changing the currently selected element, and view information in the debugging tools about any level..
To keep a record of a call stack (for example in order to indicate to other people where a problem occurred), you can [[Save call stack|save the call stack]] to a text file.
Information concerning the call stack is spread over several graphical components:
* The entire call stack, depicted as a list of elements, is displayed in the [[Call stack tool: Interface|call stack tool]] .
* [[Information relative to a stack element|Information concerning the current call stack element]] is displayed in the feature tab, the locals view, and is used to provide the expressions evaluations contained in the [[Evaluation tool or Watch tool|Expression evaluator tool]] .

View File

@@ -0,0 +1,12 @@
[[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 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 [[Object tool|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

@@ -0,0 +1,8 @@
[[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 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

@@ -0,0 +1,48 @@
[[Property:title|Supported exceptions]]
[[Property:weight|3]]
[[Property:uuid|f3b4498a-0772-32fb-041d-13428e258f52]]
Here is a list of exceptions that may appear in the [[Call stack tool: Interface|call stack tool]] . When they are raised, a tag may be there to give more information, if necessary. All these exceptions are declared in <eiffel>EXCEPT_CONST</eiffel>.
'''Feature call on Void target''': An attempt was made to call a feature on an object that is Void. The tag indicates the name of the feature of the feature that could not be called. For instance if the code line is <eiffel>a.b.c</eiffel> and the tag is "c" then <eiffel>a.b</eiffel> was Void.
'''No more memory''': A memory allocation failed.
'''Precondition violated''': One of the conditions necessary prior to entering a feature is not verified. This may indicate either that the precondition is too strong, or that the call is invalid. The tag should give the name of the violated precondition, if any.
'''Postcondition violated''': One of the conditions checked when a feature exits is not verified. This may indicate either that the postcondition is too strong, or that the feature did not behave correctly. The tag should give the name of the violated postcondition, if any.
'''Class invariant violated''': One of the conditions that checks the validity of objects is not verified. This may indicate that an object was left in an invalid state after a method call. The tag should give the name of the violated invariant, if any.
'''Assertion violated''': An assertion was not verified. The tag should give the name of the violated assertion, if any.
'''Non-decreasing loop variant''': A loop variant does not vary. This may lead to stack overflows or erroneous results.
'''Loop invariant violated''': A condition that should be checked when executing a loop is not verified. The tag should give the name of the violated invariant.
'''Floating point exception''' (signal SIGFPE): An error occurred while processing floating point numbers. This may be for example a FPU overflow, a division by zero, or an invalid operation.
'''Unmatched inspect value''': An inspect clause couldn't find the value it was passed among the `when` clauses. If any value maybe passed to the `when` clause, adding an `else` clause will solve this problem.
'''I/O error''': An error occurred while accessing a stream. Examples of this are a missing file, or insufficient rights.
'''Retrieval error''': A file could not be retrieved. This maybe caused by an invalid header, or more generally by a corrupted data file.
'''Developer exception''': Developer exceptions can be raised by calling {<eiffel>EXCEPTIONS</eiffel>}.<eiffel>raise</eiffel>. They can indicate any kind of internal error.
'''Operating system signal''': The program received a signal from the operating system.
'''Exception in rescue clause''': An exception occurred within a rescue clause.
'''Void assigned to expanded''': An attempt was made to assign a Void value to an expanded object.
'''Run-time I/O error''': Exception raised by the run-time when encountering a I/O error internally.
'''External event''': On Unix, this happens when an operating system error occurs and does not set the `errno` variable.
'''Operating system error''': On Unix, this happens when an operating system error occurs and sets the `errno` variable.
'''COM error''': Raised when EiffelCOM encounters an error.