prev up next

Menu Functions

The walkback (or context-) view offers a popup menu with the following additional (less frequently used) functions. These functions are also found in the view's main menu.

Show More
by default, only the 50 bottom contexts of the walk-back are shown. This function doubles the number of shown contexts.
(usually only relevant if the debugger was entered due to a recursion error)

Show Full Walkback
Similar to the previous function, this function changes the number of shown contexts to 9999.

Show Verbose/Dense Backtrace
toggles between full- and dense calling chain display.
In full mode, the chain is shown as you would expect: every sender is listed, up to the processes startup.
In dense mode, certain (usually less interesting) contexts are hidden (for example: intermediate #handle:do: contexts, some of the processes startup contexts, and contexts related to the handling of doIt evaluations).
Most programmers prefer the dense mode - you see more with less ;-)

The default mode for new debuggers can be changed in the launchers "source & debugger" settings menu.

Show/Hide Contexts of Helper Code
toggles between full- and dense calling chain display.
Simmilar to the previous flag, this controls if helper code of collection and exception classes is to be shown or not.
Most programmers prefer the dense mode.

This is an experimental feature and the flag may be merged with the previous flag in future versions.

Raise Debugger as Required
this toggle controls if the debugger should bring itself automatically to the front whenever it is entered. The default is true, but sometimes it is useful to keep it under some other window - especially if two or more debuggers are open at the same time.

Skip
the debugged process is single stepped until the shown method reaches or passes the sourceline in which the cursor is located.
Notice, that the singleStep mechanism is built upon trapping message sends - simple assignments or loop-entry-points are therefore not cought by this mechanism and a skip to such a line may not be reached.
However, by setting the ``detailed single step'' and ``full lineNumber info'' flags in the compilerSetting menu, higher resolution singleStepping is enabled.
You may want to turn those flags on, during development or debugging (the execution speed is somewhat reduced, though).
(Skipping is not supported by inspecting debuggers)

Step out
the debugged process is single stepped until the selected context returns or is unwound (either due to an exception or by a returning block).
(This is not supported by inspecting debuggers)

Remove Breakpoint
this menu item is enabled if the selected context has a break- or tracepoint set on its method.
If activated, the break/trace is removed.
You can resume execution of the stopped method, by pressing the "continue" button.

Remove all Breakpoints
removes all break/trace points in the system

Add a Breakpoint
adds a breakpoint to the method of the selected context. The debugger will be entered when that selected method is invoked the next time.

Ignore this Breakpoint
this allows for the breakpoint to be ignored for some number of invokations, some time or forever (i.e. until reenabled). This is very useful for breakpoints inside a loop, where we are often only interested in the first or last iteration's breakpoint.
An ignored breakpoint can be reactivated either via the debugger's menu, via the Launcher's menu, or from the Breakpoint Browser.

Do not Ignore this Breakpoint
undoes the effect of the previous "Ignore this Breakpoint" function. The selected ignored breakpoint will be reactivated (i.e. the debugger will be entered upon the next invokation).

Allow Halts in Debugger
normally, halts and breakpoints are ignored when hit while in the debugger itself. That means, for example, that a halt is ignored if reached via a "doIt" in the debugger's codeview or in an object's printString method, when shown in a subview of the debugger.
This is a very useful behavior, as it protects you from recursive debugger invokations when halts are present in such code. However, sometimes you are interested in what is going on - either if you are debugging the debugger itself, or if you are coding in the debugger, and you want to test just written code.

Browse Class
opens a browser on the class in which the selected contexts method is implemented.
A double-click on a line in the context walkBack list does the same.

Browse Class Hierarchy
opens a hierarchy browser on the class in which the selected contexts method is implemented.

Implementors
opens a browser on all implementors of the selected contexts selector.

Implementors of...
asks for a selector, then opens a browser on all implementors of that selector.

Senders
opens a browser on all senders of the selected contexts selector

Senders of...
asks for a selector, then opens a browser on all senders of that selector.

Inspect Context
opens an inspector on the selected context
(this may only be of interest to system developers)

Copy Walkback Text
places a textual representation of the walkback information into the cut & paste buffer. This text may later be pasted into a workspace, a fileBrowser or a mailTool etc. and saved into a file or sent to a bug reporting facility.
(this may only be of interest to system developers)

Quick Terminate
terminates the debugged process. Quick termination does not give the process a chance to perform any cleanup actions (in contrast to normal termination), but instead immediately kills the process.
After that, leftover views may remain visible (but are not responding) or cursors may not be restored correctly.
Only use this, if some process has problems terminating itself.

Warning:
Quick termination is provided as a last weapon (for programmers) in order to get rid of a process which refuses to terminate.
A possible situation in which this may happen is with a badly coded process termination handler (i.e. a process which catches regular termination, fails to terminate, or insists on proceeding).

A quick terminated process has no chance to perform any cleanup actions; not even unwind blocks are evaluated.
If you quick terminate a view's process, chances are high that inoperative windows are left on the display, cursors are not restored or semaphores stay blocked (all of this is normally cleaned up by unwind handlers, if properly terminated).

You can get rid of remaining views with the launchers "Destroy View" utility function (which you may have to perform multiple times, to destroy all intermediate views up to the topview - try to click on an outer view, if possible).

Blocked semaphores can be released manually, by opening a debugger on a blocking process and evaluating "self signal" in a context where that semaphore is the receiver.
The same applies to any critical regions which have been entered at termination time.

Exit Smalltalk
terminate smalltalk without saving an image
This is useful if the system got corrupted very badly, and you want to leave smalltalk without saving an image or doing any other file activity.

Big Warning:
There will be no confirmations, no cleanup or termination sequences
- ST/X will simply exit immediately.

Doc $Revision: 1.14 $ $Date: 2012/07/23 11:04:47 $