Software Review - SourceBug Reviewed

Matt Stibbe

SourceBug is a source browser, a MacApp inspector window, and a SADE-style MPW debugging utility with a Symantec-style debugger user interface.

Mike Lockwood created SourceBug to debug MacApp applications written in C++ or Object Pascal. It has some debugging facilities that are specialized for MacApp, but should also do a good job with other programs that are compiled in MPW 3.2 with the symbolic debugging information option.

This review is based on a beta release of SourceBug-version 1.0b2x1-so perhaps it is better described as a preview. It was tested with Zortech C++, MPW CFront, Pascal and C under MPW 3.2. In each case, I tested SourceBug with one or more of the standard example programs that come with MPW, using SourceBug to explore the code and functions of the application, and to trace its operation. I tested it with several MacApp-specific applications-Apple's samples-using both C++ and Pascal versions. I also tested it with a C++ application.

GETTING STARTED

SourceBug requires System 6.0.x; MultiFinder 6.1b9 (the MultiFinder that comes with SADE) or System 7; 128k ROMS; and sufficient memory to run both it and the application under test. Ideally, there should also be sufficient memory to run MPW at the same time.

SourceBug asks for a three megabytes partition. I ran it using virtual memory under System 7.0 on a Mac IIcx without obvious problems. SourceBug's compatibility with VM may ease the problem of memory squeeze when debugging large applications. MPW contributes to this problem because it requires a large slice of memory to build MacApp applications. For this reason, and due to the number of windows in use, and performance requirements, I recommend using a Mac II or better. MPW 3.2 is required since .sym information from the 3.2 linker differs from previous versions.

INSTALLATION

The review copy of SourceBug came to me as an AppleLink package that included preliminary documentation. Installation was straightforward, because you can put the application anywhere on a hard disk. When double-clicked, it uses a standard file picker to ask for the application you want to test, and takes its cues as to the .sym information from your application selection. There are no special files to put into the system folder or changes to make to the MPW setup. Under System 7, it has an attractive color icon.

Building your Application for use with SourceBug

SourceBug doesn't require making any changes to the source code of the application under test. Setting up a MacApp application for use with SourceBug is straightforward-simply use MABuild with the symbolic debugging information (-sym) option set. I was caught out at first by failing to force MPW to rebuild the whole of MacApp with "-sym" on (via MABuild … -autobuild). You can use SourceBug without a -sym version of MacApp, and make only the application build with -sym on, but this allows tracing of your application's source only, limits the evaluation of variables (for instance, via evaluating "self"), and prevents use of the inspector window.

Here's one example of an MPW command used to build one of the MacApp samples, DemoText:

MABuild demotext -names -sym -nodebug -pascal -noload

"-names" is not necessary for SourceBug, but helps with low level debuggers;Ê"-nodebug" is there because the MacApp debugger and SourceBug are partially incompatible; and "-pascal -noload" avoids bugs that exist in some versions of MPW's Pascal. You don't need to specify other special compiler directives, or make alterations to the make file, in order to use SourceBug.

Using SourceBug with a non-MacApp application is even simpler. The main thing is to run "Create Build Commands..." and to switch on "Symbolic debugger information." When the application is built, the information needed by SourceBug is saved in a separate file.

Starting a debug session

Once the application is compiled, it can be launched from within SourceBug using a standard file picker. This loads in and parses the symbolic debugging information, which can be time consuming. For example, the information for the MacApp DrawShapes sample takes 20 or 30 seconds to load. For a large MacApp application, the loading time may run into minutes. One hopes that these times will improve as SourceBug development proceeds; luckily, the files are parsed in the background.

Once the information is loaded, you can select the "Go" menu item to start the application. To break back into SourceBug, you must set up breakpoints in the source code-either before running the application, or by switching into the debugger, then setting a breakpoint in the source code browser and switching back to the application. This is unlike the Think C debugger which has a "stop" command that halts the application and gives access to the debugger-usually at "waitNextEvent." Such a feature would be a useful addition to SourceBug; presently, merely switching into SourceBug presents a blank stack crawl window.

SourceBug can debug several applications at once, which is helpful if you have a monitor large enough to arrange all the windows conveniently. SourceBug would be more usable if it included some kind of "hide other application's debugging windows" command in the windows menu like the one in the new Finder. Nevertheless, this facility will prove invaluable for developers that are working on applications that use IAC and publish and subscribe. It's also convenient for reviewers!

Browsing

Debugging activity in SourceBug has three main foci: the source code browser, tracing, and checking variables.

The window for the source code browser has three panes; each one can be resized according to taste. The window is split horizontally, and the top half is split vertically. When debugging a C program, the top left pane lists the source code files, and the top right lists the functions in the currently selected file. If the application is written in C++ and the objects do not descend from a Pascal object, the functions display with their scope, but no class hierarchy is shown. For example, in the CPlusShapesApp, the window displays TArc::Draw. It also shows constructors and destructors properly.

I did notice a glitch with two functions in CPlusShapesApp; they had almost nonsensical names, and when selected, caused repeated dialog boxes to display. This may be a failure of C++ name unmangling rather than SourceBug. Apparently, CFront generates subtly different .sym files, and SourceBug has had to be specially modified to handle these variations.

Unfortunately, Zortech C++ did not at review time generate symbolic debugger information files that were usable by SourceBug, so I couldn't test the compiler properly with it. However, applications built with MPW CFront worked well, with the one exception mentioned above. In a Pascal application that doesn't use objects, the top left window displays all the units of the application and, as before, functions and procedures on the right.

The main difference between a conventional application and a MacApp application is that in the case of MacApp, the source code browser lists object classes in the top left panel in addition to any files containing procedures or functions. For example, in the MacApp DrawShapes sample, all the classes are listed, and at the bottom is a list of Pascal units such as UFailure. The classes can be displayed alphabetically or in a hierarchy according to inheritance. The top left pane displays methods of the currently selected class.

The bottom half of the window displays the code for the selected method, procedure or function. If the debugger can't find the source code, the object code is disassembled and displayed in assembler mnemonics. You can also use a menu command to cause the code to be displayed in assembler mnemonics.

You can select and copy the source code from this window. Also, by option clicking in the window, you can open a new window showing that code. This might be useful for keeping an eye on an important function, while using the browser to look at lesser used functions, or to see a trace through the same function in source and assembly.

This feature also applies to the source code displayed in the stack crawler. Also, there is a command to show the name of the source code file from which a particular method or function derives. On the down side, the operations of source code browsing sometimes seems a little viscous. And the ability to choose the fonts for display would be welcome; for example, I prefer Helvetica over Geneva or Monaco 9 point.

Tracing

SourceBug can trace through code while it is executing and then stop at a breakpoint set in the debugger or in the source code. From the breakpoint, you can step through the code an instruction at a time or step into and out of functions.

You can also run a trace through the program by selecting "Animate" on the control menu. This steps through instructions slowly, and always yields to a mouse event in the debugger so the trace can be stopped. This is useful for people like me who are too lazy to keep pressing command-S to step. It can also be helpful for debugging interactive processes where yielding control to the debugger at every instruction would prevent normal operation of the application.

When stepping through an application under test, SourceBug displays a stack crawl window. This is divided in half by a horizontal break. The top half displays a stack of function calls. In a C application, for example, the top of the list shows "main," and then "function one" which calls "subfunction one" which is at the bottom of the stack. This is similar to the display in Think Pascal's debugger. It's useful for tracing through the methods of an object program where the flow of control can seem a rather inscrutable to a newcomer. The bottom half shows the function currently being executed in the same format as the source code browser.

As you step or trace through the application, a small pointing hand rests to the left of the instruction currently being executed. On a color display, the hand and breakpoints are shown in color. In the source code browser, when control passes to a subroutine, the hand turns grey until control returns to the visible function. However, in the stack crawler, stepping into a function brings that new function into the window. You can set breakpoints using both the stack crawl and browser windows, and any sub-windows created by option clicking on either.

As mentioned above, unlike Think C debugger, there's no way to interrupt the execution of the application from within SourceBug without first setting a breakpoint. But this is not a major inconvenience; perhaps it is only noticeable to developers reared on Think's debuggers.

Looking at Variables

SourceBug provides useful functions for monitoring variables and registers. There are commands to display FPU and CPU registers in separate windows. As with all windows in SourceBug, these update themselves automatically and continually.

There are several ways to evaluate and display variables. If you select the variable from a source code display and choose "evaluate selection," a window displays showing the contents of that variable. You can also type the variable name into a dialog box. Compound variables-such as C structures-are displayed in full, broken down into their components. Again, these variable monitor windows are updated constantly. If a variable is out of scope, SourceBug displays "out of scope" instead of a value.

It is frustrating to have each variable displayed in its own window. Think Pascal's method of monitoring several variables in one window makes for a tidier desktop, but perhaps less flexibility.

When dealing with objects, you can "evaluate self," which copes with SELF in Pascal and "this" in C++. Doing so brings up a similar window showing the variables that belong that object. Although it is titled "evaluate," no command on the evaluate menu allows expressions containing variables to be evaluated. For example, you can't evaluate "myFlag==FALSE". This is possible in language specific debuggers, because the debugger can use the language's own evaluation engine. SADE included its own procedural language, allowing similar kinds of language independent evaluations. Some form of simple evaluation would also be useful in SourceBug.

SourceBug has other features that are specific to debugging MacApp applications-see Debugging MacApp, below.

Switching TWIXT APP and SourceBug

When the user is in SourceBug, the application under test is neatly dimmed out on the Finder menu, and can't be brought to the front. This is unlike PC source level debuggers that use a "Switcher" style approach to the screen, allowing you to quickly see the current state of the application from within the debugger, but in a separate screen world and context. Even MacsBug lets you switch between the screen (as it appears to the application) and the debugging screen and back without erasing the application windows and forcing an update event.

This is probably an inevitable limitation of SourceBug's approach; the two Symantec debuggers are also limited in this fashion. You can work around it by using several monitors or one large one. If you have enough screen space, you will have problems only when there are many windows visible in both applications, when several applications are being debugged simultaneously, or when trying to debug functions to do with screen updating.

USING SourceBug with low-level debuggers

SourceBug has a "Switch to low-level debugger" command that brings the application under test to the foreground, and then enters a low level debugger such as MacsBug or TMON. A short macro for TMON Professional automates the reverse process, switching from the low level debugger back to SourceBug. There are instructions for implementing this feature using other debuggers, but Lockwood warns "the cement isn't dry [on this particular feature], so tread lightly."

During testing, I could move back and forth between SourceBug and MacsBug 6.2; I used SourceBug's command to drop into MacsBug, then MacsBug "g" command to return control back to the application, and thence back to SourceBug. Unlike Symantec's Think C source level debugger, a user break such as that caused by a Debugger() call in the source code does not enter SourceBug, but drops into the low level debugger.

It's useful to be able to embed breakpoints in the actual source code of an application. Because SourceBug is meant for use with a low level debugger and doesn't have the facility to break at A-traps, it doesn't take over control at Debugger or DebugStr. However, you can do the same thing with some little known calls defined in MPW 3.2 "Types.h" header. The SysBreak() routine is similar to Debugger(), while SysBreakStr() and SysBreakFunc() are similar to DebugStr, except that they drop into SourceBug, not MacsBug.

Debugging MacApp

SourceBug was designed primarily to assist in debugging MacApp applications. The MacApp-specific features are compatible with MacApp 2.0 final. I tested it with 2.0.1.

General object programming features

The "Implementations of method..." command can be used with any object program (except that C++ objects must descend from PascalObject), but it is most useful with MacApp. Given any selected method of a class in the browser window, this command opens a new window to list all the methods that it descends from and that it is a parent to. This list appears in the top half of the window with the "oldest" method at the top, and the youngest at the bottom. Each method is indented one space for each generation of inheritance, just as objects are in the source browser when hierarchical ordering is selected.

The code of the currently selected method is shown in the bottom half. This is useful for looking at methods that pass control back to their parents, using the INHERITED keyword in Pascal for example, where it is possible to see what each generation of the method does and how it differs from its relations. This might be useful in the descendants of the MacApp class TCommand, where a different command object exists for each menu command, but all descend from one or more base classes. You can use this command to look at all implementations of TWhateverCommand.DoIt.

Special MacApp debugging features

To monitor variables in the MacApp environment, SourceBug provides an inspector window similar to the one in the MacApp debugger (see Figure 6). It has several advantages over the MacApp inspector. First, it can be used within the SourceBug environment, which means you can see variables update automatically while stepping through the application. Second, it doesn't require you to define special fields methods for each class, as MacApp's inspector window does. You can access SourceBug's inspector window by selecting "New inspector window" from one of the menus while your application is stopped at a breakpoint.

The top left pane shows a list of all object classes, and the top right pane shows the addresses in memory of all objects of the class selected on the left that currently exist. Clicking on one of these shows the instance variables of that class in the bottom pane, as if it were a conventional compound variable.

This ability to deal with objects in memory as complete entities is useful. It would be even more useful if there were some way of connecting the classes in the top left with their source code in the source code browser. Unfortunately, the command "Find code for selection..." does not work in this way for a class selected in this window. Likewise, there is no direct way of looking at a class in the browser, and then saying something like "Show me all the instantiated objects of this type." These small omissions barely affect the utility of the debugger, but would have made its use more coherent.

SourceBug will eventually contain a special handler for MacApp's TList object, showing the contents of a list in another inspector-type window. The review version did not contain this feature.

Conclusions

SourceBug is slower that its Symantec equivalents, and the awkwardness of debugging an application in the same windowing environment as the debugger (as opposed to separating them like MacsBug or PC based source level debuggers) makes SourceBug occasionally frustrating to use.

However, these problems do not mar this excellent utility. There can be no doubt that SourceBug is an essential tool for debugging MacApp-based pro-grams. It is almost as useful in debugging object programs that do not use MacApp, and in debug- ging programs that do not use objects. Its major problem is the speed with which it runs.

Ease of Use

SourceBug's effectiveness is enhanced by its straightforward user interface. Anyone familiar with Mouser, for example, will feel instantly at home with it. Its tracing facilities are similar to the two Symantec debuggers; however, it builds on these models to add functionality. I was impressed with the way the interface makes answers to common debugging questions accessible. For example, the ability to evaluate "self" for a method under examination is a thoughtful and efficient way of connecting data with code.

SourceBug was designed for programmers by programmers, but this doesn't mean it needs a programming genius to install and operate it. Apart from the confusion caused by not compiling a MacApp library with symbolic information, I was able to use SourceBug immediately and without reference to the manual. This is, of course, in the best tradition of Mac application reviews.

The manual revealed no major surprises when I eventually read it, as a dutiful reviewer. It did contain some neat tricks that I wouldn't have noticed otherwise. Programmers familiar with the similar environments mentioned above, and MPW, might need only a page or two of instructions to do useful work with SourceBug. As for the installation and compiler options needed to get it running-nothing could be simpler.

Innovations

SourceBug is an obvious improvement over SADE by virtue of its user interface, and is clearly a peer of the two Symantec debuggers. Its particular forte is debugging MacApp applications, but in this area, too, its main features-the inspector and the special support for objects in the source-are not new but merely improved. What is new about SourceBug is the way that different functions have been combined seamlessly, and in a way that is Mac-friendly and developer-friendly.

Recommendation

Except for those skilled in using Jasik's Debugger, and confirmed SADEists, SourceBug is a must for serious MPW-based development.