Menu Functions

Main Menu

View 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, some (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 Launcher's "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, or to avoid the generation of additional expose (i.e. redraw) events for the debugged application, if the error to be debugged is raised inside a redraw function.

Process (Execution) Menu

After 5 Seconds...

Perform one of the previously described execution functions, but after some delay. This is sometimes useful when debugging code related to the current focus, event queue, popup menu or screen capture mechanisms, in order to arrange for some other view to be activated or manipulated before proceeding execution.

Skip to Cursor Line

the debugged process is single stepped until the shown method reaches or passes the sourceline in which the text cursor is located.
Notice, that the singleStep mechanism is built upon trapping message sends - simple assignments or inlined conditionals and 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 single stepping 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 in an inspecting debugger.

As an alternative, place a statement-breakpoint on the desired code line, and press the "Continue"-button.

Skip Until Return (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.

Skip Until Message...

asks for the name of a message (a selector), then the debugged process is single stepped until that message is sent.
This is not supported by inspecting debuggers.

Context (Stackframe) Menu

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)

Find...

A number of search functions which walk along the calling chain, searching for particular patterns. If found, the matching context is selected.

Remember Context and Highlight Next Time

Remembers the current walkback's frame objects, and highlights the one's which are still active when the debugger is entered the next time. This makes it very easy to identify contexts which loop or restart. I.e. it is very easy to see if a method has been called again, or is still active.

Forget Remembered Walkback

Disables the above remember feature. Notice that you should eventually stop remembering, as these contexts may hold on references to many objects which are not garbage collected otherwise.

Receiver & Selector Menus

Browse Implemented Class

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

Browse Receiver Class

opens a browser on the receiver class of the selected context. This is a different class, if the executed method is inherited from a superclass.

Implementors

opens a browser on all implementors of the selected context's 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 context's selector

Senders of...

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

Breakpoint Menu

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

Ignore this Halt

There are various additional conditions for selective ignoring of halts and method breakpoints. You need this, if you placed a breakpoint at some place which is called from other places in the system (for example: the redraw function of a scrollbar), and you want the breakpoint to be only hit when reached from inside your debugged application.

Sorry, selective ignoring is not supported for statement breakpoints by the time this document was written.

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 invocations, 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 invocation).

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 invocations 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.

Walkback Popup Menu

Hard (Quick) Terminate

terminates the debugged process. Hard termination does not give the process a chance to perform any unwind 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 a process has problems terminating itself, or if an error is reraised inside an unwind action. Always try a regular terminate before.

Warning:

Hard 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 hard terminated process has no chance to perform any cleanup actions; not even unwind blocks are evaluated.
If you hard 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 launcher's "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 launcher also offers a Semaphore Monitor view in its System menu, to find and possibly release such blocked semaphores. The same applies to any critical regions (RecursionLocks and critical blocks) which have been entered at termination time.

Also, memory leaks may be introduced as an external resource (such as external memory or OS resources) may not be properly released, if the hard terminate is performed while being inside the allocation, release or finalization code of such a resource.

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.

Continue in "Wrapped and Breakpointed Methods"...

Copyright © 1995 Claus Gittinger Development & Consulting, all rights reserved