Tools Debugger/en

Aus expecco Wiki (Version 2.x)
Zur Navigation springen Zur Suche springen

Introduction[Bearbeiten]

The Debugger is opened whenever an error or a halt/breakpoint is encountered while a Smalltalk or JavaScript elementary block's code is executed, and you have either enabled one of the "Open Debugger On..." options in the settings or started a block-test run via the "Run-and-Debug" button (the red "play" button).

A variant of the debugger is opened if an error or breakpoint is encountered in a bridged Node.JS or bridged Python action.

Currently the debugger cannot be used with Groovy and with code which is executed on a remote machine or in an external JVM.

If the debug options are disabled in the settings, no debugger will be shown, and the action is finished with an Error-verdict.

Typical situations in which the debugger pops up are Division-by-Zero, Index-Bounds-Errors, File-Not-Found-Errors etc. However, the debugger is also opened if you put a breakpoint (or a programmed halt) into your elementary block's code.

The debugger's full documentation is part of the official Smalltalk/X Online Documentation.

This is an expert tool, useful to coders only.

Aborting vs. Terminating vs. Proceeding[Bearbeiten]

If you are not interested in further investigation of the error, simply press the "Abort" button to finish the current activity (with an Error-verdict).

Avoid the red "Terminate" button, as this will kill the underlying thread. This should be only used as a last chance, when an error is reported again and again. Often termination will close the underlying thread's window, which may be the expecco-window. Always first try to "Abort" a few times before terminating.

Some errors are proceedable, if they are considered to be non-severe. For example a "File-Not-Found" error might be proceedable and the program would then continue with a nil file handle (which may of course lead to future errors, if the nil-handle is ever used for I/O operations). The proceedability depends on the way the error was signalled and is usually a choice of the programmer (i.e. whether the code which uses a file is prepared to deal with a nil handle). In most situations, they are not proceedable, and the "Continue" button will be disabled.

Single Stepping[Bearbeiten]

Single stepping within the elementary code is possible via the "Next", "Step" and "Send" buttons. "Next" does linewise single stepping, "Step" performs the next call inside the selected function (both do not step into called functions), and "Send" goes into called functions.

All of these three buttons always operate within the currently selected function (in the top list). Thus, you do not have to step through all the internal low-level code; just select a frame higher in the calling hierarchy, and step there.

The popup-menu offers another useful function "Step until Cursor Line". For this, place the text-cursor (of the code editor) to the line and select this menu function. If the line is reached by the code, the debugger will regain control. Otherwise an notification ("context returned") will be shown.

What is Shown by the Debugger[Bearbeiten]

The debugger displays the state of the suspended program in multiple panes. The top pane shows a walkback (also named "call chain"), presenting the calling functions, callers below the called function. Click to select one of the callers to see how and where it called the function in error.

When selected, the function's source code and current execution line number is shown in the middle pane.

Notice, that you should have checked the "Install Source Code" toggle in the initial installation; otherwise, the debugger will not be able to show the source code. If you did not, please repeat the installation process, checking the "Install Source Code" toggle.
Also notice, that not all of expecco's source code is deployed and published. Only the parts of the underlying open source Smalltalk/X code can be seen (which can also be downloaded from the Smalltalk/X web site, or accessed via the CVS repository).

The lower pane displays the contents of the receiving object (i.e. the object of which a function was called) on the left, and call-arguments plus local variables of the function on the right.
These are standard inspector windows, so they allow code evaluation ("doIt") and following references by double click on a selected item.

Programming in the Debugger[Bearbeiten]

One of the unique features of Smalltalk (and therefore of expecco) is the ability to change the code in the debugger and proceed. If your elementary code block contains an error, you can interactively write new code in the debugger, try it via "DoIt" or "PrintIt" and finally "Accept" (i.e. install your changed code). When the block is invoked the next time, the new code will be executed.

If you want to repeat the block's invocation with the new code immediately, press the "Resend" button. This restarts the selected function from the top (you can also move up/down in the calling hierarchy of the walkback and restart other functions).

Due to the way code is compiled and the amount of debugging information compiled into the system, some functions are not restartable. If this is the case, select one further up, and restart that one. But be careful to not navigate beyond the caller of your elementary block, otherwise you may end up restarting the whole test-suite or test-case.

Things You Cannot Change[Bearbeiten]

Expecco protects itself from modifications done to itself. So you cannot modify code of the expecco application. Actually, since only the source code of the basic framework classes is deployed, you will not even be able to see the internals of the expecco system.

This is not a bug but done by purpose.

Entering the Debugger via the Interrupt Key[Bearbeiten]

If the system seems to no longer react (or is executing an endless loop), you should normally be able to stop/pause the execution via the execution control buttons. In very rare situations, these may seem to not react, and the systems seems frozen. This happens if a system lock (semaphore) is kept and not freed, or if a high priority process executes an endless loop. Although we take good care to avoid/find/and fix such situations, and they are really very very rare, you can still interrupt the system with the interrupt key, which is CTRL-., CMD-. or INTR/PAUSE, depending on your operating system and keyboard layout. This interrupts the current activity and opens a debugger on the activity. The "Test Run" tab also includes an interrupt toolbar button for this at the top right side.

Depending on the operating system used (Linux vs. MS Windows vs. Mac-OSX), some operations cannot be interrupted. For example, on Windows, some of the system API calls are uninterruptable.

Back to Online Documentation.



Copyright © 2014-2024 eXept Software AG